clicolors-control? #88
Comments
|
It's not a dependency but the env var is still supported. 176f99f |
Merged
Archina
pushed a commit
to Archina/console
that referenced
this issue
Apr 5, 2021
fix args in vim -N -u NONE
dtolnay
pushed a commit
to dtolnay-contrib/console
that referenced
this issue
Feb 4, 2022
This branch updates the console application to: - Detect what colors are supported by the current terminal and choose them accordingly - Allow user settings to override the color palette - Allow user settings to override whether particular UI elements are colored This change is rather complicated. It introduces `clap` for CLI arguments, to allow the user to override the color palette. When the color palette is _not_ overridden, the console will determine what colors the terminal supports via the following process: - If the `COLORTERM` environment variable is set to "24bit" or "truecolor", this indicates that the terminal supports 24-bit RGB color. In that case, all colors are used. - Otherwise, the console attempts to use `tput colors` to query the `terminfo` database to see what colors the current terminal supports. - If the call to `tput colors` fails, we assume no colors are supported. Additionally, new CLI args allow the user to toggle whether durations are color-coded, and whether terminated tasks are dimmed. In the future, we will probably also want to add support for parsing these from a config file --- in general, users probably won't want to set these preferences from the command line every time they run the console. However, I decided to punt on adding a config file in this PR --- the addition of new CLI arg parsing logic is a big enough change. We can add a simple TOML file or something in a follow-up change. Signed-off-by: Eliza Weisman <[email protected]>
dtolnay
pushed a commit
to dtolnay-contrib/console
that referenced
this issue
Feb 4, 2022
Depends on console-rs#88 Depends on console-rs#89 This branch builds on the CLI flags added in console-rs#88 to also add support for disabling the use of non-ASCII characters in the console. The console will now attempt to detect whether the terminal supports UTF-8 by inspecting the `LANG` environment variable. If the value ends with `UTF-8`, unicode characters will be used. If it does not, the console will run in an ASCII-only mode. Furthermore, the CLI now includes a `--lang` flag to override the value of the `LANG` environment variable, and a `--ascii-only` flag to force the ASCII-only mode. When Unicode support is disabled, we do the following: - replace the "play", "pause", and "stop" characters added in console-rs#89 with `>`, `:` and `!`, respectively. I'm open to suggestions, if anyone can think of better ASCII characters to represent the "running", "idle", and "completed" states. - the use of Unicode characters for the left, right, up, and down arrow keys, enter key, and escape key in the controls list is replaced with simply spelling out the names of those keys. - the use of Unicode box-drawing characters in the task details window is avoided by disabling borders entirely. It would be nice to eventually replace this with ASCII art borders, but TUI doesn't have a way to provide a custom character set for borders, as far as I can tell. - the Unicode micro symbol (mu) in microsecond durations is replaced with `u`, for `us`. - the poll time histogram is disabled entirely, since TUI's sparklines rely on Unicode block characters. This was implemented by changing the `view::Colors` struct, which determines what colors are enabled based on the configuration, to `view::Styles`, and making it also responsible for determining what character set is enabled. It now is responsible for determining how to style more UI elements. ### Screenshots: ```console $ cargo run ``` Task list:  Task details:  ```console $ cargo run -- --ascii-only ``` Task list:  Task details:  ### Future Work - Handle cases where `LANG` includes other Unicode character sets (e.g. UTF-16)? - Also use `LANG` and other locale env variables for localization. Right now, we only look at the last part of the `LANG` variable, which determines the character set, but the first part of it determines the locale (e.g. on my machine, `LANG=en_US.UTF-8`). Doing proper localizations is likely to be a big pile of work, though, just in terms of actually translating text into languages other than English. There are probably existing libraries that could be used for the 'mechanical' parts (actually switching UI text), but the translations kind of inherently require human intervention... - Use ASCII art borders when Unicode is disabled? - Figure out an acceptable way to draw the histograms without Unicode characters? This may not really be possible... Signed-off-by: Eliza Weisman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The documentation refers to
clicolors-controla few times but that doesn't appear to be a dependency of this project. Am I misunderstanding something or is this a small mistake in the docs?The text was updated successfully, but these errors were encountered: