2020-06-20 03:41:53 +00:00
|
|
|
[package]
|
2022-03-13 18:30:27 +00:00
|
|
|
authors = ["The Nushell Project Developers"]
|
2020-06-20 03:41:53 +00:00
|
|
|
description = "Nushell table printing"
|
2022-08-14 12:21:20 +00:00
|
|
|
repository = "https://github.com/nushell/nushell/tree/main/crates/nu-table"
|
2022-01-20 13:13:45 +00:00
|
|
|
edition = "2021"
|
2021-09-10 02:27:12 +00:00
|
|
|
license = "MIT"
|
|
|
|
name = "nu-table"
|
2022-12-20 08:58:48 +00:00
|
|
|
version = "0.73.0"
|
2020-06-20 03:41:53 +00:00
|
|
|
|
|
|
|
[dependencies]
|
2022-06-03 19:38:54 +00:00
|
|
|
nu-ansi-term = "0.46.0"
|
2022-12-20 08:58:48 +00:00
|
|
|
nu-protocol = { path = "../nu-protocol", version = "0.73.0" }
|
|
|
|
nu-utils = { path = "../nu-utils", version = "0.73.0" }
|
|
|
|
nu-engine = { path = "../nu-engine", version = "0.73.0" }
|
|
|
|
nu-color-config = { path = "../nu-color-config", version = "0.73.0" }
|
color_config now accepts closures as color values (#7141)
# Description
Closes #6909. You can now add closures to your `color_config` themes.
Whenever a value would be printed with `table`, the closure is run with
the value piped-in. The closure must return either a {fg,bg,attr} record
or a color name (`'light_red'` etc.). This returned style is used to
colour the value.
This is entirely backwards-compatible with existing config.nu files.
Example code excerpt:
```
let my_theme = {
header: green_bold
bool: { if $in { 'light_cyan' } else { 'light_red' } }
int: purple_bold
filesize: { |e| if $e == 0b { 'gray' } else if $e < 1mb { 'purple_bold' } else { 'cyan_bold' } }
duration: purple_bold
date: { (date now) - $in | if $in > 1wk { 'cyan_bold' } else if $in > 1day { 'green_bold' } else { 'yellow_bold' } }
range: yellow_bold
string: { if $in =~ '^#\w{6}$' { $in } else { 'white' } }
nothing: white
```
Example output with this in effect:
![2022-11-16 12 47 23 AM - style_computer
rs_-_nushell_-_VSCodium](https://user-images.githubusercontent.com/83939/201952558-482de05d-69c7-4bf2-91fc-d0964bf71264.png)
![2022-11-16 12 39 41 AM - style_computer
rs_-_nushell_-_VSCodium](https://user-images.githubusercontent.com/83939/201952580-2384bb86-b680-40fe-8192-71bae396c738.png)
![2022-11-15 09 21 54 PM - run_external
rs_-_nushell_-_VSCodium](https://user-images.githubusercontent.com/83939/201952601-343fc15d-e4a8-4a92-ad89-9a7d17d42748.png)
Slightly important notes:
* Some color_config names, namely "separator", "empty" and "hints", pipe
in `null` instead of a value.
* Currently, doing anything non-trivial inside a closure has an
understandably big perf hit. I currently do not actually recommend
something like `string: { if $in =~ '^#\w{6}$' { $in } else { 'white' }
}` for serious work, mainly because of the abundance of string-type data
in the world. Nevertheless, lesser-used types like "date" and "duration"
work well with this.
* I had to do some reorganisation in order to make it possible to call
`eval_block()` that late in table rendering. I invented a new struct
called "StyleComputer" which holds the engine_state and stack of the
initial `table` command (implicit or explicit).
* StyleComputer has a `compute()` method which takes a color_config name
and a nu value, and always returns the correct Style, so you don't have
to worry about A) the color_config value was set at all, B) whether it
was set to a closure or not, or C) which default style to use in those
cases.
* Currently, errors encountered during execution of the closures are
thrown in the garbage. Any other ideas are welcome. (Nonetheless, errors
result in a huge perf hit when they are encountered. I think what should
be done is to assume something terrible happened to the user's config
and invalidate the StyleComputer for that `table` run, thus causing
subsequent output to just be Style::default().)
* More thorough tests are forthcoming - ran into some difficulty using
`nu!` to take an alternative config, and for some reason `let-env config
=` statements don't seem to work inside `nu!` pipelines(???)
* The default config.nu has not been updated to make use of this yet. Do
tell if you think I should incorporate that into this.
# User-Facing Changes
See above.
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace --features=extra -- -D warnings -D
clippy::unwrap_used -A clippy::needless_collect` to check that you're
using the standard code style
- `cargo test --workspace --features=extra` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2022-12-17 13:07:56 +00:00
|
|
|
atty = "0.2.14"
|
2022-10-20 12:52:15 +00:00
|
|
|
tabled = { version = "0.10.0", features = ["color"], default-features = false }
|
2022-12-15 14:47:04 +00:00
|
|
|
json_to_table = { version = "0.3.1", features = ["color"] }
|
2022-10-18 22:44:04 +00:00
|
|
|
serde_json = "1"
|
2022-12-19 23:53:17 +00:00
|
|
|
|
|
|
|
[dev-dependencies]
|
2022-12-20 08:58:48 +00:00
|
|
|
nu-test-support = { path="../nu-test-support", version = "0.73.0" }
|