Posted by tosh 17 hours ago
If the 256c palette is generated from a -- potentially wild -- 16c palette then there is no guarantee anymore that 146 will indeed be the 146 I expect.
Turning 16-255 into the same kind of minefield as 0-15 seems very misguided to me.
And the developers answer to this loss of control is to create multiple colour schemes and allow the user to configure the app. Which then means their users have to set up their terminal defaults and then configure every fscking app that ignores those terminal defaults(!!!) instead of defining their required colour schemes once in the terminal.
People use the terminal not because it’s pretty but because they find a text interface more efficient. If you want to make pretty things then build a web frontend. But please do not break my terminal because you feel the need to impose on me your own favourite colours of the hour.
If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.
https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...
Kind of anal about this since I started with a lot of CGA and EGA displays when I was in my late teens and early 20s and relatively involved in the ANSi art scene.
Here's a related project I'm working on for playing doors in a web browser.
They could also have done something about the two magentas though... E.g. made one of them orange?
I have to select that text to change the background to read it.
But there is no standard or standard body anywhere for terminal colors so there is no obvious way to improve this situation.
And no urgency either, because all terminal emulators allow users to customize the palette anyway.
There's no obvious way to unilaterally improve the situation across the whole ecosystem, that's true. But I don't understand why individual terminal emulator maintainers don't fix it for their users.
FWIW, the current de-facto standard is set by xterm. Here is a relevant excerpt of its source code:
! Disclaimer: there are no standard colors used in terminal emulation.
!
! The choice for color4 and color12 is a tradeoff between contrast, depending
! on whether they are used for text or backgrounds. Note that either color4 or
! color12 would be used for text, while only color4 would be used for a
! background. These are treated specially, since the luminosity of blue is
! only about half that of red/green, and is typically not accounted for in the
! RGB scheme.
!
! Blue text on a black background should be readable.
! Blue backgrounds should not be "too" bright.
!
! Originally color4/color12 were set to the names blue3/blue
!*VT100*color4: blue3
!*VT100*color12: blue
!
! They are from rgb.txt respectively:
! 0 0 205 blue3
! 0 0 255 blue
! However, blue3 is not readable on a black background.
!
! Another choice was from the Debian settings:
!*VT100*color4: DodgerBlue1
!*VT100*color12: SteelBlue1
!
! From rgb.txt:
! 30 144 255 DodgerBlue1
! 99 184 255 SteelBlue1
!
! Some users object to this choice because the background (color4) is brighter
! than they are accustomed. Others point out that the different weights for
! the red/green components make it appear to be not really blue. Finally, it
! provides poor contrast against color13 and color14.
!
! The current choice uses equal weights for red/green (effectively adding a
! gray to the result). It is brighter than the original choice, and provides
! more contrast between color12 and color13, color14 than SteelBlue1 did.
! Contrast of color4 against black is slightly improved over the original.
!
! Some refinement is certainly possible (you are welcome to try) -TD
Make that what you will :-).That’s true for 256 colour and various other escape codes too. But I wouldn’t say it’s true for 16 colour pallet.
Similarly, the user can also set their own fonts for the terminal, just as you can with colours and other functions. (However, some programs will have a reason to configure the fonts and palettes for the specific use, although most won't and even if they do the user might disable those features.)
A program can have an option (possibly by environment variable) to disable colours entirely; this might be necessary even if you can disable colours in the terminal emulator, because a program might want to use such things as reverse video, underlined text, etc to indicate some things when colours are disabled. (Disabled colours can also be useful if you do not have a colour display or if you want to print out a screenshot without a colour printer.)
An even bigger one is hardcoding black and white instead of using foreground/background and use reverse when needed.
But I wonder what the developers of gdb were using that made them not notice this
now that react devs finished destroying the web they have to impose their superior taste into terminal through 800mbs TUIs.
Please just don't. This is not the web.
Color usage in the terminal should be largely semantic, not stylistic.
Speaking for the group of people I know and work with, we don't want a "consistent experience" and hate TUIs that try to manhandle the color palette. Use color sparingly and with intention. Respect that different people have different settings.
Outside of my text editor, where colors matter a lot to me for syntax highlighting, I'm definitely in the NO_COLORS camp (and in the NO_EMOJI camp, nowadays).
> Color usage in the terminal should be largely semantic, not stylistic.
I wholeheartedly agree but 0-15 sadly have zero inherent semantics, which is the single reason behind every terminal colors-related drama since forever: developer choses 9 to highlight an error message because it is generally a bright red by default --> user sets 9 to whatever makes sense to them --> error message is illegible.
I don’t want my applications to decide “this element must be red text on green background.” I want my applications to annotate the UI with things like “warning message” and “title.”
e.g.
Foreground Background Purpose
----------- ----------- -------
ESC[38:99:0m ESC[48:99:0m normal ( same as ESC[39m and ESC[49m )
ESC[38:99:1m ESC[48:99:1m emphasise
ESC[38:99:2m ESC[48:99:2m de-emphasise
ESC[38:99:3m ESC[48:99:3m error
ESC[38:99:4m ESC[48:99:4m warning
ESC[38:99:5m ESC[48:99:5m caution
ESC[38:99:6m ESC[48:99:6m notice
Then people (themes) could easily choose foreground colour or background highlighting for particular roles. Some terminal emulators might also choose to configure other stylistic choices like bold, italic, etc.(I believe ISO8613-6 defines sub-modes 0 through 5 (te;db), with 2 (rgb) and 5 (256-color indexed) being most widely implemented. But some terminals historically mess up : and ; in CSI sequences, and I know at least one would interpret ESC[38:6:1m as ESC[6;1m (blinking bold!), so here I pick 99 (ECMA-48 defines modes up to 65).)
Anyone interested, ping me (address in profile) and encourage me to set up a repo to discuss and formulate a concrete proposal.
I’m working on a terminal emulator. It’s not big like Ghostty but this is something I might adopt
One alternative: Assign semantics to colour indexes above 256.
Both of those have the disadvantage that they separate foreground and background colour, but a user really wants a combined semantic presentation. For instance, a user might want a warning message to be black text on a yellow background, and not have to rely on the program remembering to set both foreground and background to ‘warning’ colour.
So another possibility is just to invent new SGR numbers, e.g.
Control Purpose
------------ -------
CSI 2 0 0 m normal (undoes any CSI 1 x x m)
CSI 2 0 1 m emphasise
CSI 2 0 2 m de-emphasise
CSI 2 0 3 m error
CSI 2 0 4 m warning
CSI 2 0 5 m caution
CSI 2 0 6 m notice
⋮
Then the user can configure those as they please with any combination of foreground, background, weight, slant, etc.I'm now thinking about writing up pros and cons of alternatives.
- Apprentice, a low-contrast colorscheme I made years ago and used for a long time: https://github.com/romainl/Apprentice.
- Malotru, my curent colorscheme, more contrasted: https://github.com/romainl/vim-malotru.
- Dichromatic, for colorblind users: https://github.com/romainl/vim-dichromatic.
- Bruin, which only uses typography: https://git.sr.ht/~romainl/vim-bruin
I have one here: https://github.com/romainl/vim-sweet16 but it is intentionally weird and essentially unmaintained.
We have many millenia of books using black text on a white background with various colors added, why are computer monitors all of a sudden so special and annoying
And because monitors are giant light bulbs. So a large white background is harder on the eyes than black.
Is there anything you can do with that information though? This piece of information only becomes useful if you know what colour the background is. And you should also know the colour of text and everything else.
What if the background is muted violet? What if the background is white and the foreground is muted violet? I don't want you to ever use "muted violet" in my terminal, since you have no idea what colours there are in my terminal.
The exact values of your 0-15 don't matter to me and they don't matter to you either, because you chose to use my 256c colorscheme to begin with.
Then you're not really covered by the article? A colorscheme is all about... color. A TUI is about the content and function. I think there's room to have user-defined 256 palettes that are used by default, while colorschemes can use true color and be chosen by the user if they desire.
I would posit then that this article simply doesn't apply to you at all. The feature being described is targetted at users who are effectively developing their own schemes (albeit in a rather simplified automated manner). If I'm taking something off the shelf, I'm using the appropriate recommended base16. I have no expectation that a wild base16 is going to align with any 3rd-party's curated scheme.
I do understand that this logic isn't always going to click with people given the differing contexts of a terminal-wide -vs- app-specific (i.e. vim) approach, but again: that disparity seems either a legacy issue (caused by things like this 16-256 mis-alignment) OR simply a philosophical difference (whereby people who customise at the term level shouldn't at the app level & vice-versa).
Instead of aiming to provide a "consistent experience", you should instead prioritize providing consistent functionality, while avoiding impeding users' control over their own particular experience.
If the user sets a sensible 16 color palette though, many old utils could look great out of the box. I'm enticed by the idea.
Having all terminal emulators run the equivalent of colorcoke without asking the user is not a very bright idea.
I personally prefer light themes everywhere, both in IDEs and in the terminal. I thought that just choosing my own color scheme for 0-15 would give me the color pallette that I prefer, but because app developers like you for some reason decided that you know better what colors do I prefer, this is actually not enough. I also have to configure each TUI application separately to have the color scheme that I like.
And I do not understand why people do it. Like, why would you deliberately break the universal customization system and force users to use your own, specific to your app?
Honesty, each time I encounter an app that uses 16-255 colors, I feel like someone just violated my personal space and intruded into my chosen color pallette with their own colors that don't fit.
Because all my work is based on 16-255, I can actually guarantee to my users that, given a properly configured terminal emulator, they will get the colors on the screenshots.
If I can't rely on 16-255 to be fixed anymore, then I won't be able to make any promise anymore. In practice, it just means adding a caveat in the README.md, but I'd prefer not to. Here's hoping this breaking change gets hidden behind a checkbox/flag.
But defaults should be simple.
XKCD 1172? https://xkcd.com/1172/
What would be optimal is semantic _styles_ (not colors):
- The developer marks the string "XXX" as an error message without even trying to style it.
- The platform/user agent/terminal/whatever displays the string in the default style for "error".
- The user can adjust the theme of their platform/user agent/terminal/whatever to fit their needs/wants.
We use an ansible task to ensure SYSTEMD_COLORS=16 is in /etc/environment on every system and it at least solves that problem...
I didn't read in fully, but what I was thinking in my head is not that we would just totally replace the rest of the colors with arbitrary palette. But that we would sub in better versions of the palette that also used user colors as the base. What was magenta is derived from what the user picked from blue and red.
There's always been such tension between design/creative and users. Apps & designers want their own brand identity, want creative control to make things just so. And are willing to throw user preference & desire on the pyre to get that exacting control. Personally that was always rubbed me extremely the wrong way; I would way rather allow some weirdness & funkiness in, if it leaves the user in control. But I understand the risk aversion, understand the Murphy's law corporatism that makes people and companies want to build strong laws that forbid anything but strictly approved systems, for fear that things go wrong. I understand. But I also things that's a dogshit world to live in.
0-15 are, as I said, a minefield because they are user-customizable: there is no guarantee whatsoever that my user's 1 will be the same dark-ish red as mine… or that it will be dark-ish… or that it will even be vaguely red-ish. It is actually somewhat fun to design colorschemes within those crazy constraints but oh well.
On the other side of the spectrum, truecolors is a nice idea in principle but support is still spotty and inconsistent. In theory, this gives me, the designer, full control over the colors used in the UI, which is a good thing for us and for my users. In fine, if I want my colorscheme to be usable by most users, then I can't blindly rely on this.
Which leaves me with 16-255, which are more widely supported than truecolors and, more importantly, dependable. They have problems, as mentioned in the article, but their _fixed_ nature gives me confidence that the background color of the status-line, for example, will look exactly the same -- and exactly how I want it to look -- in all my user's environments. Which, again, is good for my users and for me. Losing that confidence is what worries me, here.
Like you said, maybe 146 will still be a muted violet —— just not exactly the same -- but I'm not sure about this and I think that, at the minimum, this "feature" should be put behind a checkbox/flag.
You define a baseline color in HSV and then everything else is a multiplier of that
For example
[style]
HSV = [0.7, 0.5, 0.5]
Dark = { H = 1.0, S = 1.2, V = 0.25 } # Make dark elements less saturated and darker
Symbol = { H = 1.0, S = 1.8, V = 1.8 } # Make symbols more vibrant
As a result you can simply move around the HSV to your preference in the config and things don't look like garbage where you have to hand tweak every color to get something legible.
For example, this simple loop https://github.com/day50-dev/Streamdown?tab=readme-ov-file#c...
It's effectively a swatch
Though, I have a problem with even just the basic 16 colours:
black red green yellow blue magenta cyan white bright black bright red bright green bright yellow bright blue bright magenta bright cyan bright white
~~~
Many themes take `black` to mean `black` and `white` to mean `white`. How is it supposed to work when one switches the theme between the dark and the light version?
What are `black`, `white`, `bright black`, and `bright white` supposed mean?
I take those as meaning (in order): `almost invisible on current terminal background`, `pretty contrasty`, `visible but not contrasty`, and `the contrastiest`.
I wish the colour names reflected that, instead of `black` and `white`: you usually care about the contrast, not about the precise colour.
By the way, the terminal foreground and background colors are independent of the standard 16 colors, which complicates things.
That makes sense, but... seems infeasible in practice? "The program"? I tell you what program I need to configure: all of them! Ideally even the programs I'm not even using yet.
I think I'll continue doing it my wrong way then: redefining the meanings to mean less/more contrasty. That allows me to effortlessly switch the terminal between light[0] and dark[1] backgrounds. I've done worse things: I also hijacked a part of the 256-colors-cube for my own purposes...
[0]: https://github.com/tasuki/dotrc/blob/master/.config/kitty/so...
[1]: https://github.com/tasuki/dotrc/blob/master/.config/kitty/so...
Although, this should probably be optional (both as an option for terminals to have in their own settings, and via an escape sequence that opts out), because some users will have configured some programs with a color scheme that they don't want transformed. For example, if your terminal uses the Solarized color scheme, and your text editor _also_ uses the Solarized color scheme, then this could lead to double-applying a color transform and getting something odd.
Perhaps instead of the application overriding the setting, it could be done with an environment var, so the user can easily override it if the mapping messes with the look/usability of the program.
It’s been a fairly decent stop gap measure. I use tinted shell to switch between color schemes.
Maybe applying the saturation of the base set across all the generated palette would also work.
> Fewer terminals support truecolor.
From what I know all modern terminal emulators in all operating systems support it now.
urxvt prominently doesn't (fully)
At the currently known limits of physics where Heisenberg Uncertainty Principle, Abbe's Limit, Quantum Shot Noise and such become our sensing barriers, we suspect we need only about 6000 bits per pixel to represent a digital twin of the electromagnetic field of the sensor-covered volume of space. At 60 fps, that is 1.8 Zettabits per second. Scale out data volume accordingly when using using 18.5 sexdecillion fps (Planck time fps).
What surprises me is these "limits of the fabric of reality as we know it" mind experiments fairly concretely point the way on the many roads towards Kardashev Scale implementations, and is not that different from Archimedes' "Sand Reckoner" and Hindu cosmological Kalpa time scales. History doesn't quite repeat, but rhymes yet again.
There are different programs inside the terminal that I would prefer to have different color treatment. A full-fledged editor like emacs should have full 24-bit color support because I have already configured it to have my preferred color schemes and I prefer to switch themes inside emacs. On the other hand, almost all other TUI programs should not be permitted to use more than the traditional 16 colors. I haven’t configured them myself so I don’t trust them to make good choices.
In other words different terminal capabilities for different programs.
So, I've started using AI models to generate color schemes for me.
Take an unreadable theme I like and generate one that is high contrast and still coherent. It's probably not good enough for a full spectrum vision person to use but wow has it improved my quality of life.
It wouldn't surprise me if this is exactly the type of problem that is solved in the same way for the rest of you
I am not colorblind, and have the same experience. It's made worse by the fact that different apps use colors differently, so if I find a theme that works well for some clis and tuis, there will be others that will have unreadably low contrast with the default theme. So I have to tweak the colorscheme for each application as well.