1. 17
  1. 13

    I’m quite skeptical of the real world value of 24bit color in a terminal at all, but the biggest problem I have with most terminal colors is they don’t know what the background is. So they really must be fully user configurable - not just turn on/off, but also select your own foreground/background pairs - and this is easier to do with a more limited palette anyway.

    I kinda wish that instead of terminal emulators going down the 24 bit path, they instead actually defined some kind of more generic yet standardized semantic palette entries for applications to use and for users to configure once and done to get across all applications.

    alas.

    1. 4

      I’m quite skeptical of the real world value of 24bit color in a terminal at all

      I have similar misgivings, but I admit to liking the result of 24-bit colour. It’s useful! I just don’t like how it gets there.

      Something that is a never-ending source of problems with the addition of terminal colours in the output of utilities these days is that in almost every case they are optimized for dark mode. I don’t use, nor can I stand, dark mode. It is horrible to read. But as a result, the colour output from the tools is unreadable. bat is the most recent one I tried. I ran it on a small C file and I literally couldn’t read most of the output.

      Yes, you can configure them but when they are useless out-of-the-box, the incentive is very low to want to configure everything. And then, I could just… not configure them and use the standard ones that are still just fine.

      Terminal colours are really useful. I find 24-bit colour Emacs in a terminal pretty nice. It’s the exception. Most other modern terminal tools that produce colour output don’t work for me because they can’t take into account my current setup.

      Having standard colour pallettes that the tools could access would be much better.

      1. 4

        I’ve started polling my small sample size of students and they almost unanimously prefer dark mode. I suspect this is most people’s preferred which is why it’s the default of most tools.

        Personally I prefer dark because I have a lot of floaters in my eyes that are distracting with light backgrounds. For many years I had to change the defaults to dark.

        That said, I like to be able to toggle back and forth between light and dark. When I’m outside in the sun, or using a projector, light mode is critical. This is made difficult by every tool using their own color palette rather than the terminal’s. Some tools can be configured to do so, and maybe that should be their default.

        1. 5

          I suspect this is most people’s preferred which is why it’s the default of most tools.

          Back when I was in undergrad (~25 years ago), light mode was what everyone used. Then again, it was always on a CRT monitor and was the default for xterms everywhere. If you got a dark theme happening, it attracted some attention because you knew what you were doing. People did it to show off a bit. (I did it too!)

          Then I got older and found dark backgrounds remarkably difficult to read from. I haven’t used them for well over 15 years. I simply cannot read comfortably on a such colour schemes, which why I have to use reader view or the zap colours bookmarklet all the time.

          I’m not saying dark mode is bad, but I am saying it’s probably trendy. I suspect things will swing in a different direction eventually, especially as the eyes of those who love it now get older. (They inevitably get worse! Be ready for it.) So the default will likely change. In which case, maybe we should really consider not hard-baking colour schemes into tools and move the colour schemes to somewhere else, as you mention. This is the better way to go. As I mention elsewhere in the thread, configuring bat, rg, exa, and all these modern tools individually is just obnoxious. Factor the colour schemes out of the tools somehow. It’s a better solution in the long run.

          1. 1

            I too find light displays easier to read.

            From memory, the first time I heard of TCO-approved screens was when Fujitsu(?) introduced a CRT screen with high resolution, a white screen, and crisp black text. This was considered more legible and more ergonomic.

            (TCO is Tjänstemännens Centralorganisation, the main coordinating body of Swedish white-collar unions. Ensuring a good working environment for their members is a core mission.)

            1. 2

              What I find helps the most is reducing the blue light levels - stuff like f.lux works well.

              I’m also looking into e-ink monitors, but damn, they’re pricey.

        2. 3

          Yeah, I’m a fan of light mode (specifically white backgrounds) on screen most the time too, and actually found colors so bad that’s a big reason why I wrote my own terminal emulator. Just changing the palette by itself wasn’t enough, I actually wanted it to adjust based on dynamic background too (so say, an application tries to print blue on black, my terminal will choose a different “blue” than if it was blue on white, having the terminal emulator itself do this meant it would apply to all applications without reconfiguration, it would apply if i did screen -d -r from a white screen to a black screen (since the emulator knows the background, unlike the applications!), and would apply even if the application specifically printed blue on black since that just drives me nuts and I see no need to respect an application that doesn’t respect my eyes).

          A little thing, but it has brought me great joy. Even stock ls would print a green i found so hard to read on white. And now my thing adjusts green and yellow on white too!

          Whenever I see someone else advertising their new terminal emulator, I don’t look for yet another GPU render. I look to see what they did with colors and scrollback controls.

          1. 2

            I got fed up with this and decided to do something about it, so after what felt like endless fiddling and colorspace conversions, I have a color scheme that pretty much succeeds at making everything legible, in both light and dark mode. It achieves this by

            • Deriving color values from the L*C*h* color space to maximize the human-perceived color difference.
            • Assigning tuned color values as a function of logical color (0-15), whether it’s used for foreground or background, and whether it’s for dark or light mode.
            • Assigning the default fg/bg colors explicitly as a 17th logical color, distinguished from the 16 colors assignable by escape sequences.

            As a result, I can even read black-on-black and white-on-white text with some difficulty.

            Here it is: https://github.com/svenssonaxel/st/blob/master/config.h#L117-L207

            1. 2

              I had the same problem with bat so I contributed 8-bit color schemes for it: ansi, base16, and base16-256. The ansi one is limited to the 8 basic ANSI colors (well really 6, since it uses the default foreground instead of black/white so that it works on dark and light terminals), while the base16 ones follow the base16 palette.

              Put export BAT_THEME=ansi in your .profile and bat should look okay in any terminal theme.

              1. 2

                As I said, I could set the theme, but my point was that I don’t want to be setting themes for all these things. That’s maintenance work I don’t need.

                1. 1

                  I definitely agree that defaulting to 24 bit colour is a terrible choice for command line tools, but when it’s a single environment variable to fix, I do think some (bat) are worth the minor, one-off inconvenience.

            2. 3

              I agree 100%. I think the closest thing we have to a standardized semantic palette is the base16 palette. It’s a bit confusing because it’s designed for GUI software too, not just terminals, so there are two levels of indirection, e.g. base16 0x8 = ANSI 1 = red-ish. It works great for the first eight ANSI colors:

              base16  ANSI  meaning
              ======  ====  ==========
              0x0     0     background
              0x8     1     red-ish/error
              0xb     2     green-ish/success
              0xa     3     yellow-ish
              0xd     4     blue-ish
              0xe     5     violet-ish
              0xc     6     cyan-ish
              0x5     7     foreground
              

              The other 8 colors are mostly monochrome shades. You need these for lighter text (e.g. comments), background highlights (e.g. selections), and other things. The regular base16 themes place these in ANSI slots 8-15, which are supposed to be the bright colors, which breaks programs that assume those slots have the bright colors.

              The base16-256 variants copy slots 1-6 into 9-14 (i.e. bright colors look the same as non-bright, which is at least readable), and then puts the other base16 colors into 16-21. It recommends doing this maneuver with base16-shell, which IMO defeats the purpose of base16. base16-shell is just a hack to get around the fact that most terminal emulators don’t let you configure all the palette slots directly; kitty does, so I use my own base16-kitty theme to do that, and use base16-256 for vim, bat, fish, etc. without base16-shell.

            3. 1

              There is a lot of discussion here about light vs. dark backgrounds. So, you may be interested in a solution I devised allowing configs of both kinds simultaneously keyed off of a shell environment variable LC_THEME. You do need to set it at terminal launch time, but it is inheritable from a wrapper script. So, you can say LC_THEME=darkBG termLaunch -dark or just have a term-dark script.

              ssh (up until recently) will even propagate LC_* variables for all the locale switches. (Recently, it made these rules more specific.) So, even without admin access you can(/could?) propagate this information to remote shells without “encode it in $TERM or etc. tricks. It’s very low tech - much easier/simpler/more portable than writing your own terminal emulator and doing hot palette swaps. When you think about it, terminal theming is much like other locale variables.

              This approach does have the burden of “two or more configs” for any program using color. A third might be dim-pastel background, for example, but there are only so many themes/schemes with rich color variety and high contrast. Besides the psychophysical/visual system reasoned mentioned so far, some use background diversity as a “context code” (SuperUser, remote-to-X, etc.). (For me personally, it was just one dead pixel and a desire for 2 side-by-side terminals. Lol.)

              An example of two color themes/schemes is here (you may have to scroll a bit, but if you care about this topic then you might also like the lc program). I did arrange for “conforming programs” to all share the layer of indirection. So, with any cligen program like the color ps/top/vmstat procs or hldiff there can be one centralized lightBG and darkBG config.