2022-12-15 14:47:04 +00:00
|
|
|
mod common;
|
2022-11-16 14:03:56 +00:00
|
|
|
|
2022-12-15 14:47:04 +00:00
|
|
|
use common::{create_row, create_table};
|
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:
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
|
|
|
|
2023-08-04 18:50:47 +00:00
|
|
|
use nu_table::{NuTableConfig, TableTheme as theme};
|
2022-11-16 14:03:56 +00:00
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn test_expand() {
|
2022-12-15 14:47:04 +00:00
|
|
|
let table = create_table(
|
|
|
|
|
vec![create_row(4); 3],
|
2023-08-04 18:50:47 +00:00
|
|
|
NuTableConfig {
|
|
|
|
|
theme: theme::rounded(),
|
|
|
|
|
with_header: true,
|
|
|
|
|
expand: true,
|
|
|
|
|
..Default::default()
|
|
|
|
|
},
|
2022-12-15 14:47:04 +00:00
|
|
|
50,
|
|
|
|
|
);
|
|
|
|
|
|
2022-11-16 14:03:56 +00:00
|
|
|
assert_eq!(
|
2022-12-15 14:47:04 +00:00
|
|
|
table.unwrap(),
|
2022-11-16 14:03:56 +00:00
|
|
|
"╭────────────┬───────────┬───────────┬───────────╮\n\
|
|
|
|
|
│ 0 │ 1 │ 2 │ 3 │\n\
|
|
|
|
|
├────────────┼───────────┼───────────┼───────────┤\n\
|
|
|
|
|
│ 0 │ 1 │ 2 │ 3 │\n\
|
|
|
|
|
│ 0 │ 1 │ 2 │ 3 │\n\
|
|
|
|
|
╰────────────┴───────────┴───────────┴───────────╯"
|
|
|
|
|
);
|
|
|
|
|
}
|
