2022-10-03 18:40:16 +02:00
|
|
|
use std::collections::HashMap;
|
|
|
|
|
2023-02-22 19:35:45 +01:00
|
|
|
use crate::{string_width, Alignments, TableTheme};
|
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 14:07:56 +01:00
|
|
|
use nu_color_config::StyleComputer;
|
2022-10-03 18:40:16 +02:00
|
|
|
use nu_protocol::{Config, Span, Value};
|
2022-12-15 15:47:04 +01:00
|
|
|
use tabled::{
|
2023-02-22 15:10:17 +01:00
|
|
|
color::Color,
|
|
|
|
formatting::AlignmentStrategy,
|
|
|
|
object::Segment,
|
|
|
|
papergrid::{records::Records, GridConfig},
|
|
|
|
Alignment, Modify,
|
2022-12-15 15:47:04 +01:00
|
|
|
};
|
2022-10-03 18:40:16 +02:00
|
|
|
|
2023-02-22 15:10:17 +01:00
|
|
|
use serde_json::Value as Json;
|
|
|
|
|
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 14:07:56 +01:00
|
|
|
/// NuTable has a recursive table representation of nu_protocol::Value.
|
2022-10-03 18:40:16 +02:00
|
|
|
///
|
Fix typos by codespell (#7600)
# Description
Found via `codespell -S target -L
crate,ser,numer,falsy,ro,te,nd,bu,ndoes,statics,ons,fo,rouge,pard`
# User-Facing Changes
None.
# Tests + Formatting
None and done.
# After Submitting
None.
2022-12-26 08:31:26 +01:00
|
|
|
/// It doesn't support alignment and a proper width control.
|
2022-10-03 18:40:16 +02:00
|
|
|
pub struct NuTable {
|
2023-02-22 19:35:45 +01:00
|
|
|
inner: String,
|
2022-10-03 18:40:16 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
impl NuTable {
|
|
|
|
pub fn new(
|
|
|
|
value: Value,
|
|
|
|
collapse: bool,
|
|
|
|
config: &Config,
|
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 14:07:56 +01:00
|
|
|
style_computer: &StyleComputer,
|
2022-10-03 18:40:16 +02:00
|
|
|
theme: &TableTheme,
|
|
|
|
with_footer: bool,
|
|
|
|
) -> Self {
|
|
|
|
let mut table = tabled::Table::new([""]);
|
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 14:07:56 +01:00
|
|
|
load_theme(&mut table, style_computer, theme);
|
2022-10-03 18:40:16 +02:00
|
|
|
let cfg = table.get_config().clone();
|
|
|
|
|
2023-02-22 19:35:45 +01:00
|
|
|
let val = nu_protocol_value_to_json(value, config, with_footer);
|
|
|
|
let table = build_table(val, cfg, collapse);
|
2022-10-03 18:40:16 +02:00
|
|
|
|
2023-02-22 19:35:45 +01:00
|
|
|
Self { inner: table }
|
|
|
|
}
|
2023-02-22 15:10:17 +01:00
|
|
|
|
2023-02-22 19:35:45 +01:00
|
|
|
pub fn draw(&self, termwidth: usize) -> Option<String> {
|
|
|
|
let table_width = string_width(&self.inner);
|
2023-02-22 15:10:17 +01:00
|
|
|
if table_width > termwidth {
|
2023-02-22 19:35:45 +01:00
|
|
|
None
|
|
|
|
} else {
|
|
|
|
Some(self.inner.clone())
|
2023-02-22 15:10:17 +01:00
|
|
|
}
|
2022-10-03 18:40:16 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-02-22 15:10:17 +01:00
|
|
|
fn build_table(val: Json, cfg: GridConfig, collapse: bool) -> String {
|
|
|
|
let mut table = json_to_table::json_to_table(&val);
|
|
|
|
table.set_config(cfg);
|
|
|
|
|
|
|
|
if collapse {
|
|
|
|
table.collapse();
|
|
|
|
}
|
|
|
|
|
|
|
|
table.to_string()
|
|
|
|
}
|
|
|
|
|
|
|
|
fn nu_protocol_value_to_json(value: Value, config: &Config, with_footer: bool) -> Json {
|
2022-10-03 18:40:16 +02:00
|
|
|
match value {
|
|
|
|
Value::Record { cols, vals, .. } => {
|
|
|
|
let mut map = serde_json::Map::new();
|
|
|
|
for (key, value) in cols.into_iter().zip(vals) {
|
|
|
|
let val = nu_protocol_value_to_json(value, config, false);
|
|
|
|
map.insert(key, val);
|
|
|
|
}
|
|
|
|
|
2023-02-22 15:10:17 +01:00
|
|
|
Json::Object(map)
|
2022-10-03 18:40:16 +02:00
|
|
|
}
|
|
|
|
Value::List { vals, .. } => {
|
|
|
|
let mut used_cols: Option<&[String]> = None;
|
|
|
|
for val in &vals {
|
|
|
|
match val {
|
2023-01-24 12:23:42 +01:00
|
|
|
Value::Record { cols, .. } => {
|
|
|
|
if let Some(_cols) = &used_cols {
|
2022-10-03 18:40:16 +02:00
|
|
|
if _cols != cols {
|
|
|
|
used_cols = None;
|
|
|
|
break;
|
|
|
|
}
|
2023-01-24 12:23:42 +01:00
|
|
|
} else {
|
|
|
|
used_cols = Some(cols)
|
2022-10-03 18:40:16 +02:00
|
|
|
}
|
2023-01-24 12:23:42 +01:00
|
|
|
}
|
2022-10-03 18:40:16 +02:00
|
|
|
_ => {
|
|
|
|
used_cols = None;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if let Some(cols) = used_cols {
|
|
|
|
// rebuild array as a map
|
|
|
|
if cols.len() > 1 {
|
|
|
|
let mut arr = vec![];
|
|
|
|
|
|
|
|
let head = cols.iter().map(|s| Value::String {
|
|
|
|
val: s.to_owned(),
|
|
|
|
span: Span::new(0, 0),
|
|
|
|
});
|
|
|
|
let head = build_map(head, config);
|
|
|
|
|
2023-02-22 15:10:17 +01:00
|
|
|
arr.push(Json::Object(head.clone()));
|
2022-10-03 18:40:16 +02:00
|
|
|
|
|
|
|
for value in &vals {
|
|
|
|
if let Ok((_, vals)) = value.as_record() {
|
|
|
|
let vals = build_map(vals.iter().cloned(), config);
|
|
|
|
|
|
|
|
let mut map = serde_json::Map::new();
|
2023-02-22 15:10:17 +01:00
|
|
|
connect_maps(&mut map, Json::Object(vals));
|
2022-10-03 18:40:16 +02:00
|
|
|
|
2023-02-22 15:10:17 +01:00
|
|
|
arr.push(Json::Object(map));
|
2022-10-03 18:40:16 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if with_footer {
|
2023-02-22 15:10:17 +01:00
|
|
|
arr.push(Json::Object(head));
|
2022-10-03 18:40:16 +02:00
|
|
|
}
|
|
|
|
|
2023-02-22 15:10:17 +01:00
|
|
|
return Json::Array(arr);
|
2022-10-03 18:40:16 +02:00
|
|
|
} else {
|
|
|
|
let mut map = vec![];
|
2023-02-22 15:10:17 +01:00
|
|
|
let head = Json::Array(vec![Json::String(cols[0].to_owned())]);
|
2022-10-03 18:40:16 +02:00
|
|
|
|
|
|
|
map.push(head.clone());
|
|
|
|
for value in vals {
|
|
|
|
if let Value::Record { vals, .. } = value {
|
|
|
|
let list = Value::List {
|
|
|
|
vals,
|
|
|
|
span: Span::new(0, 0),
|
|
|
|
};
|
|
|
|
let val = nu_protocol_value_to_json(list, config, false); // rebuild array as a map
|
|
|
|
|
|
|
|
map.push(val);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if with_footer {
|
|
|
|
map.push(head);
|
|
|
|
}
|
|
|
|
|
2023-02-22 15:10:17 +01:00
|
|
|
return Json::Array(map);
|
2022-10-03 18:40:16 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
let mut map = Vec::new();
|
|
|
|
for value in vals {
|
|
|
|
let val = nu_protocol_value_to_json(value, config, false);
|
|
|
|
map.push(val);
|
|
|
|
}
|
|
|
|
|
2023-02-22 15:10:17 +01:00
|
|
|
Json::Array(map)
|
2022-10-03 18:40:16 +02:00
|
|
|
}
|
2023-02-22 15:10:17 +01:00
|
|
|
val => Json::String(val.into_abbreviated_string(config)),
|
2022-10-03 18:40:16 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn build_map(
|
|
|
|
values: impl Iterator<Item = Value> + DoubleEndedIterator,
|
|
|
|
config: &Config,
|
2023-02-22 15:10:17 +01:00
|
|
|
) -> serde_json::Map<String, Json> {
|
2022-10-03 18:40:16 +02:00
|
|
|
let mut map = serde_json::Map::new();
|
|
|
|
let mut last_val: Option<Value> = None;
|
|
|
|
for val in values.rev() {
|
|
|
|
if map.is_empty() {
|
|
|
|
match last_val.take() {
|
|
|
|
Some(prev_val) => {
|
|
|
|
let col = val.into_abbreviated_string(&Config::default());
|
|
|
|
let prev = nu_protocol_value_to_json(prev_val, config, false);
|
|
|
|
map.insert(col, prev);
|
|
|
|
}
|
|
|
|
None => {
|
|
|
|
last_val = Some(val);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
let mut new_m = serde_json::Map::new();
|
|
|
|
let col = val.into_abbreviated_string(&Config::default());
|
|
|
|
|
2023-02-22 15:10:17 +01:00
|
|
|
new_m.insert(col, Json::Object(map));
|
2022-10-03 18:40:16 +02:00
|
|
|
map = new_m;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
map
|
|
|
|
}
|
|
|
|
|
2023-02-22 15:10:17 +01:00
|
|
|
fn connect_maps(map: &mut serde_json::Map<String, Json>, value: Json) {
|
|
|
|
if let Json::Object(m) = value {
|
2022-10-03 18:40:16 +02:00
|
|
|
for (key, value) in m {
|
|
|
|
if value.is_object() {
|
|
|
|
let mut new_m = serde_json::Map::new();
|
|
|
|
connect_maps(&mut new_m, value);
|
2023-02-22 15:10:17 +01:00
|
|
|
map.insert(key, Json::Object(new_m));
|
2022-10-03 18:40:16 +02:00
|
|
|
} else {
|
|
|
|
map.insert(key, value);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 14:07:56 +01:00
|
|
|
//
|
|
|
|
fn load_theme<R>(table: &mut tabled::Table<R>, style_computer: &StyleComputer, theme: &TableTheme)
|
|
|
|
where
|
2022-10-03 18:40:16 +02:00
|
|
|
R: Records,
|
|
|
|
{
|
2023-02-16 20:32:07 +01:00
|
|
|
let mut theme = theme.into_full().unwrap_or_else(|| theme.theme.clone());
|
2022-10-03 18:40:16 +02:00
|
|
|
theme.set_horizontals(HashMap::default());
|
|
|
|
|
|
|
|
table.with(theme);
|
|
|
|
|
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 14:07:56 +01:00
|
|
|
// color_config closures for "separator" are just given a null.
|
|
|
|
let color = style_computer.compute("separator", &Value::nothing(Span::unknown()));
|
|
|
|
let color = color.paint(" ").to_string();
|
|
|
|
if let Ok(color) = Color::try_from(color) {
|
|
|
|
table.with(color);
|
2022-10-03 18:40:16 +02:00
|
|
|
}
|
2022-12-15 15:47:04 +01:00
|
|
|
|
|
|
|
table.with(
|
|
|
|
Modify::new(Segment::all())
|
|
|
|
.with(Alignment::Horizontal(Alignments::default().data))
|
|
|
|
.with(AlignmentStrategy::PerLine),
|
|
|
|
);
|
2022-10-03 18:40:16 +02:00
|
|
|
}
|