Hacker News Reader

Comment by Tor3 | Hacker News Reader

I have a problem with all terminal tools that insist on using colors to distinguish between various file types or attributes etc ('ls' is often set up like that too for distros, but I simply delete the config which sets that, the default doesn't). I use a terminal background which is easy on my eyes, and those color schemes always include colors which clash with the background or makes them hard to see in other ways. In short - I don't want colors in my 'ls' or 'ls' equivalent output. I'm fine with what ls with '-AFC' gives me.

View on HN

If tooling would simply use the Base16 Framework[0] instead of arbitrary colors from “256 color” or “RGB” color modes, this would be much less of a problem: the output would always be displayed with (presumably) readable colors defined by your terminal.

[0] https://github.com/chriskempson/base16

[1] https://tinted-theming.github.io/base16-gallery/

As a CLI tool author, I don't understand how I can use base16 to "theme" my tool's output. Can you point to some resources?

It’s the first 16 colors of the 256 set. Most current graphical terminals support the latter, but they only expose the first 16 in their configuration. So using them makes your software completely customizable. I believe the tty console only use the first 8.

I'm not sure if eddyg had a different idea, but I think the following sums it up:

  - base16 is a specification of how different UI elements map to colors [1], and also some tooling, configuration files, etc. to automate setting this up for many different applications.
  - For a user to be able to use base16 with a tool, either:
    - Allow the user to set their preferred colors for UI elements at a semantic level, preferrably in a config file, and even more preferrably in a separate file that can be included into the main config file so that it's easier to automate (i.e. I have a separate `colors.sh` that is loaded in my `.zshrc`).
    - Let the user set their shell colors however they want (presumably using [2]), and use the ANSI shell colors (and a few more) according to the base16 style guide [1]. Some translation between shell colors and base16 colors will be necessary, e.g. base16 says that a language keyword should use the color base0E, which in [2] corresponds to ANSI shell color 13.

My impression is that the base16 specification is not sufficiently general for most tools to implement it in a totally unbambiguous way, but if users can set their own colorschemes with a config file, it's not hard for a user to come up with a base16-approximating colorscheme template file, from which other users can generate a config file that sets a specific base16 colorscheme.

[1]: https://github.com/chriskempson/base16/blob/main/styling.md [2]: https://github.com/chriskempson/base16-shell

I'm not sure that I fully understood the theming aspect but one point I think is that the standard 8/8 ANSI colors are presumably picked to be readable by the terminal theme itself, independent from your application.

So if you just use those in your application you don't know the actual colors that the user will see on their screen but you know that they will be something readable.

> the output would always be displayed with (presumably) readable colors

There are several obstacles that make this not the case in practice, unfortunately. Black on white and white on black (whatever hex colors those actually are) will look fine. But different applications will use the accent colors differently. For example, some might use black text on a colored background, and others may use colored text on a black background. Some tools even use “bright” colored text on a different colored background. This is masked in most cases by iTerm2’s “Minimum contrast” setting, but when I tried to design a color palette with good contrast with that setting off, I found it to be very difficult.

I'm totally the other way around, I rely on colorized output heavily.

But! There's supposed to be a solution to this, set $NO_COLOR to some value. https://no-color.org

Totally reasonable to file a bug report against tools which don't check and respect that env variable.

30-odd years of using ls and this comment is finally the catalyst for me to start using -A instead of -a. Thank you!

https://no-color.org

You can use vivid [1], choose a proper theme that works for your terminal background and load the generated LS_COLORS variable into your shell.

[1]: https://github.com/sharkdp/vivid/

I work on VS Code. We have a feature for this exact problem that enforces a minimum contrast ratio of 4.5:1 via shifting the luminance of the foreground text by default https://code.visualstudio.com/docs/terminal/appearance#_mini... . This feature's in xterm.js so any terminal based on xterm.js can leverage this.

We actually got a bit of push back when this was released but I haven't heard anything for quite a while now that some time has passed and we have a FAQ for colors not being "correct".

Solarized is easy on the eyes and the colours are chosen for readability.

https://ethanschoonover.com/solarized/

The list on the site lacks some entries. Konsole has it built in and i bet Gnome Terminal too.

Pet peeve, Solarized makes no sense as a terminal color scheme, because it maps brgreen, brblue, bryellow, and brcyan to barely-distinguishable shades of gray. It just doesn't have enough colors in its palette to cover the range of colors that the authors of CLI tools expect your terminal to be able to display.

Also, Solarized's whole trick is that its colors are perceptually uniform in terms of lightness, and I think the results speak for themselves why we don't do this in practice. If you want a yellow that actually looks yellow and not a shade of puke brown, it needs to be brighter than the other colors (especially red, which needs to be darker than the other colors if you don't want it to look pink).

I’ve used solarised-light in my terminal for a few years. I really enjoy the colours, but you’re absolutely right, it is not actually terminal friendly. Many programs just write invisible text.

It also makes the baffling decision to make "bright black" darker than "black." Pretty much every other terminal colorscheme renders brightblack as a dark gray.

It's fine as an editor colorscheme, but nearly unusable as a terminal scheme.

It's not easy on my eyes. It looks washed out with too low contrast.

--color=never

Reply on news.ycombinator.com