Add NO_COLOR support #89
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is the wrong way to do it. Color detection is done by |
|
Sorry for the trouble but I was told in #88 that |
|
@lambdagolem yeah. we're going to revert this. See #91 |
This was referenced Mar 15, 2021
dtolnay
pushed a commit
to dtolnay-contrib/console
that referenced
this pull request
Feb 4, 2022
…s#89) This branch replaces the "kind" column in the tasks list view with a new "state" column that indicates whether the task is currently running, idle, or terminated. The "kind" column was initially intended to distinguish between Tokio's blocking tasks and async tasks, but the task's fields column also conveys this information, so the "kind" column was really just useful for indicating whether the task was active or terminated. Distinguishing vs sleeping and idle tasks here makes this column somewhat more useful. The task list can also be sorted by the state column. We may want to consider making this the default sorting in the future... This currently uses the Unicode "play", "pause", and "stop" symbols, as proposed in console-rs#25, to display the different task states. In a subsequent change, I'll add support for detecting and determining whether UTF-8 is supported by the terminal.  Signed-off-by: Eliza Weisman <eliza@buoyant.io>
dtolnay
pushed a commit
to dtolnay-contrib/console
that referenced
this pull request
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 <eliza@buoyant.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The NO_COLOR variable appears to be a bit of a standard variable for handling this. See https://no-color.org/.
termcoloralso supports this https://docs.rs/termcolor/1.1.2/i686-unknown-linux-gnu/termcolor/enum.ColorChoice.html.