2021-12-16 13:17:29 +01:00
|
|
|
[package]
|
2022-03-22 21:25:38 +01:00
|
|
|
authors = ["The Nushell Project Developers"]
|
2022-04-11 20:17:06 +02:00
|
|
|
description = "Color configuration code used by Nushell"
|
2022-08-14 14:21:20 +02:00
|
|
|
repository = "https://github.com/nushell/nushell/tree/main/crates/nu-color-config"
|
2022-03-22 21:25:38 +01:00
|
|
|
edition = "2021"
|
|
|
|
|
license = "MIT"
|
2021-12-16 13:17:29 +01:00
|
|
|
name = "nu-color-config"
|
2023-05-17 14:59:01 +02:00
|
|
|
version = "0.80.1"
|
2021-12-16 13:17:29 +01:00
|
|
|
|
2023-02-12 23:22:00 +01:00
|
|
|
[lib]
|
|
|
|
|
bench = false
|
|
|
|
|
|
2021-12-16 13:17:29 +01:00
|
|
|
[dependencies]
|
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
|
|
|
serde = { version="1.0.123", features=["derive"] }
|
|
|
|
|
|
2023-05-17 14:59:01 +02:00
|
|
|
nu-protocol = { path = "../nu-protocol", version = "0.80.1" }
|
2023-03-13 23:38:18 +01:00
|
|
|
nu-ansi-term = "0.47.0"
|
2023-05-17 14:59:01 +02:00
|
|
|
nu-utils = { path = "../nu-utils", version = "0.80.1" }
|
|
|
|
|
nu-engine = { path = "../nu-engine", version = "0.80.1" }
|
|
|
|
|
nu-json = { path="../nu-json", version = "0.80.1" }
|
2022-12-20 00:53:17 +01:00
|
|
|
|
|
|
|
|
[dev-dependencies]
|
2023-05-17 14:59:01 +02:00
|
|
|
nu-test-support = { path="../nu-test-support", version = "0.80.1" }
|
