The good thing with the 256c palette is that colors in the 16-255 range are fixed, which gives us a very high level of confidence that 146 will be a muted violet and so on. This is very useful for colorscheme developers because it allows us to provide a pretty good and consistent experience across the widest range of terminal emulators.
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.
I know 16 colours is limiting, but one of my biggest pet peeves is CLI / TUI developers creating their own custom themes using colours outside of that because odds are, they’re going to generate a colour scheme that is harder to read for a lot of people with visual impairments, people who prefer a white or coloured background for eye comfort, people are dyslexic and find non-black backgrounds easier to read, and others with visual difficulties, reading difficulties, or those who just like a different colour scheme per project or environment they’re working in so they can multitask more easily.
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.
I agree. I always customize the blue color on my terminal because dark blue on black is completely unreadable to me (and I'm not even color blind!). For some reason, every single terminal emulator defaults to a blue that's unreadable on a black background (I think typically #00f).
If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.
Yes, I know that (see the venerable https://github.com/trapd00r/colorcoke, etc.) but those tricks are not used widely enough for them to be a concern. Using those tricks is also a deliberate choice so it is definitely on the user if my lovingly crafted 256c colorscheme is broken.
Having all terminal emulators run the equivalent of colorcoke without asking the user is not a very bright idea.
This will be fascinating to see in practice, with ghostty for example shipping these changes! I expect that the concern you have here will largely be for naught, with some exception. What are some terminal apps you think might be affected, what are test cases?
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.
Yeah, when you point it out, this makes complete sense and every terminal should probably add this feature. I think I would generalize this to 24-bit color as well; 16 colors isn't enough to identify a unique tonemap, but if you fiddle with the parameters a bit I think it shouldn't be too hard to come up with something hacky that works.
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.
Interesting. You could build a LUT from the 16 color palette to map the 24 bit color space to something 24 bits or less. A bit like mapping 10 bit HDR to 24 bit sRGB.
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.
What I would like is HDR colors, just to access more saturated light colors. I don't want less saturated blue to make it lighter, just crank up the blue channel to 11. I still don't want brighter colors than #fff though.
I think your wish is self-contradicting. `#fff` is so-called _device_ colour -- a device like a LED-based display uses it directly to drive the LEDs, where `#fff` means that the red, the green and the blue channel are already "cranked to 11". The `f` here is equivalent to 11. HDR uses a different color format, I think -- exactly because `#fff` is otherwise either ambigous, or has to map to a different colour gamut -- where, for instance, `#fff` actually means the whitest white cranked up to 11, at however many nits (say 1500) the monitor may emit, which would make your "standard" or "SDR" white (per sRGB, say) that's usually has the emitted strength of around 100 nits, be somewhere at `#888` (I haven't taken into account the _curve_ implied here, at any rate I don't think it's going to be a linear relationship between nits and device primary N-bit colour numbers).
Also, `#fff` is ambigous -- if you mean device colour, then there's no brightness (nits) specified at all, it may be 200 or 2000 or 10,000. If sRGB is implied, as in `#fff in sRGB colour space` then the standard specifies 80 nits, so when you say you don't want brighter than that, then you can't have much of HDR since sRGB precludes HDR by definition (can't go brighter than 80 nits for the "whitepoint" aka white).
I think if you want HDR you need a different colour space entirely, which either has a different peak brightness, or one where the brightness is specified additionally to e.g. R, G and B primaries. But here my HDR knowledge is weak -- perhaps someone else may chime in. I just find colour science fascinating, sorry to go on a tangent here.
This definitely seems like a sensible starting option to generate 256 colours from a custom set of 8 (and then let the really pedantic users fiddle with the extended set). I would presume for "standard" themes these values would be pregenerated and adjusted slightly if needed.
It's perennially baffling to me why we're still clinging to VT220/xterm compatible terminals. I even see people claiming they prefer working in the terminal, though it's not clear to me what type of work those people are doing.
Give me a proper graphical application any day, but I recognize that it's historically been a lot more work to produce a GUI in the pre-LLM era.
But golly gee whizz if we're going to keep the command line around, can we move on from 1983?
GUI apps are good for discoverability. They generally are not optimized for rapid use by power users though. That's of course not an inherent limitation of GUI apps, it's just that dominant paradigms hardly seem to consider power users.
I'm still annoyed and baffled by the fact that Ubuntu had searchable application menus 10 years ago, which were awesome and worked for just about any program, and then dropped them when they abandoned Unity. And neither KDE not Gnome thought to bring them back. In stead, many apps have since dropped application menus entirely, in favour of... some mishmash of icons and ad hoc menu buttons?
Also, even in the post-LLM era, building a decent GUI app is a lot more work than building a decent terminal app.
Another factor is the lack of a good cross-platform GUI toolkit (by which I mean one that (a) doesn't feel out-of-place and jarring on any platform and (b) doesn't turn a 50K app into a 1GB download.)
Between that and the level of complexity of modern GUI toolkits - and the size of their dependency trees - distribution of a GUI app is a much bigger headache than distributing a terminal app.
Graphical applications are great if your workflow mirrors the workflow that the GUI was designed for. However if your workflow differs then you’ll often be fighting the GUI.
Think of it like different types of programming languages. Some are more suited on different types of problems than others.
For me, my workflow is about composing and gluing different processes together rather than using a standard defined tool repeatedly in the same way as that tools UI was originally designed. So the CLI is ideally suited for me in all the areas where a GUI would be high friction.
Terminals are text. Text adds features missing from gui namely:
* Ad Hoc
requirements change and terminal gives ultimate empty workbench flexibility. awesome for tasks you never new you had until that moment.
* Precision
run precisely what you want, when you want it. you are not constrained by gui UX limits.
* Pipeline
cat file.txt | perl/awk/sed/jq | tee output.result
* Equal Status
everything is text so you can combine clipboard, files, netcat output, curl output and then you can transform (above) and save. whatever you like in whatever form you like, named whatever you like.
Why? There is huge compatibility layer build on top of this and changing even these minor things will break stuff in places you do not expect. Want a fancy terminal? Install another one. By default most allow changing to many terminal formats. Break things to move forward is fun when it's not your problem to solve down the line.
It's a shame to see you get downvoted (presumably because you don't cite any evidence for your assertions). As a counter-point, I will give the oft-quoted-by-me 1990s promotional video of the use of IBM CallPath on an AS/400 which should get you all misty-eyed https://youtu.be/5pY6Xxptp9A?t=2058
The good thing with the 256c palette is that colors in the 16-255 range are fixed, which gives us a very high level of confidence that 146 will be a muted violet and so on. This is very useful for colorscheme developers because it allows us to provide a pretty good and consistent experience across the widest range of terminal emulators.
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.
I know 16 colours is limiting, but one of my biggest pet peeves is CLI / TUI developers creating their own custom themes using colours outside of that because odds are, they’re going to generate a colour scheme that is harder to read for a lot of people with visual impairments, people who prefer a white or coloured background for eye comfort, people are dyslexic and find non-black backgrounds easier to read, and others with visual difficulties, reading difficulties, or those who just like a different colour scheme per project or environment they’re working in so they can multitask more easily.
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.
I agree. I always customize the blue color on my terminal because dark blue on black is completely unreadable to me (and I'm not even color blind!). For some reason, every single terminal emulator defaults to a blue that's unreadable on a black background (I think typically #00f).
If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.
> but one of my biggest pet peeves is CLI / TUI developers creating their own custom themes
An even bigger one is hardcoding black and white instead of using foreground/background and use reverse when needed.
There are escape codes that can re-define palette entries. Usually including the 16-255 range.
Yes, I know that (see the venerable https://github.com/trapd00r/colorcoke, etc.) but those tricks are not used widely enough for them to be a concern. Using those tricks is also a deliberate choice so it is definitely on the user if my lovingly crafted 256c colorscheme is broken.
Having all terminal emulators run the equivalent of colorcoke without asking the user is not a very bright idea.
Terminals like iTerm2 have had a Minimum Contrast for a while that messes with (foreground) colours, sometimes very badly.
This will be fascinating to see in practice, with ghostty for example shipping these changes! I expect that the concern you have here will largely be for naught, with some exception. What are some terminal apps you think might be affected, what are test cases?
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.
I have a bunch of Vim colorschemes under my belt.
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.
It’s a messy situation for sure and what lead me to discover tinted theming: https://github.com/tinted-theming/base24/
It’s been a fairly decent stop gap measure. I use tinted shell to switch between color schemes.
Yeah, when you point it out, this makes complete sense and every terminal should probably add this feature. I think I would generalize this to 24-bit color as well; 16 colors isn't enough to identify a unique tonemap, but if you fiddle with the parameters a bit I think it shouldn't be too hard to come up with something hacky that works.
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.
Interesting. You could build a LUT from the 16 color palette to map the 24 bit color space to something 24 bits or less. A bit like mapping 10 bit HDR to 24 bit sRGB.
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.
What I would like is HDR colors, just to access more saturated light colors. I don't want less saturated blue to make it lighter, just crank up the blue channel to 11. I still don't want brighter colors than #fff though.
I think your wish is self-contradicting. `#fff` is so-called _device_ colour -- a device like a LED-based display uses it directly to drive the LEDs, where `#fff` means that the red, the green and the blue channel are already "cranked to 11". The `f` here is equivalent to 11. HDR uses a different color format, I think -- exactly because `#fff` is otherwise either ambigous, or has to map to a different colour gamut -- where, for instance, `#fff` actually means the whitest white cranked up to 11, at however many nits (say 1500) the monitor may emit, which would make your "standard" or "SDR" white (per sRGB, say) that's usually has the emitted strength of around 100 nits, be somewhere at `#888` (I haven't taken into account the _curve_ implied here, at any rate I don't think it's going to be a linear relationship between nits and device primary N-bit colour numbers).
Also, `#fff` is ambigous -- if you mean device colour, then there's no brightness (nits) specified at all, it may be 200 or 2000 or 10,000. If sRGB is implied, as in `#fff in sRGB colour space` then the standard specifies 80 nits, so when you say you don't want brighter than that, then you can't have much of HDR since sRGB precludes HDR by definition (can't go brighter than 80 nits for the "whitepoint" aka white).
I think if you want HDR you need a different colour space entirely, which either has a different peak brightness, or one where the brightness is specified additionally to e.g. R, G and B primaries. But here my HDR knowledge is weak -- perhaps someone else may chime in. I just find colour science fascinating, sorry to go on a tangent here.
Terminals should be able to show images, so you could run Jupyter notebooks in them.
Terminals can show images https://sw.kovidgoyal.net/kitty/graphics-protocol/
This is a limitation of UNIX terminals, in other platforms not tied to a no longer existing tty interface, this isn't an issue.
Unfortunely, given that we are stuck with UNIX derived OSes, this is indeed a possible issue.
However I would argue, for fancy stuff there is the GUI right there.
This definitely seems like a sensible starting option to generate 256 colours from a custom set of 8 (and then let the really pedantic users fiddle with the extended set). I would presume for "standard" themes these values would be pregenerated and adjusted slightly if needed.
> Complex and color-heavy programs struggle with such a small palette.
Damn if only there was some other system that could be operating with that in mind
I feel like you're saying one operating system does it better, but I fail to think of one.
Windows allows you to set any pixel to any 24-bit colour.
Not really an OS thing, you can get 24 bit 'true' colour on Linux/macOS too depending on term. Alacritty supports it, for example.
Agree, and I love how concise, yet persuasive and practical this proposal is.
Terminals should not exist, emulating a serial teletype emulating a Hollerith machine
It's perennially baffling to me why we're still clinging to VT220/xterm compatible terminals. I even see people claiming they prefer working in the terminal, though it's not clear to me what type of work those people are doing.
Give me a proper graphical application any day, but I recognize that it's historically been a lot more work to produce a GUI in the pre-LLM era.
But golly gee whizz if we're going to keep the command line around, can we move on from 1983?
GUI apps are good for discoverability. They generally are not optimized for rapid use by power users though. That's of course not an inherent limitation of GUI apps, it's just that dominant paradigms hardly seem to consider power users.
I'm still annoyed and baffled by the fact that Ubuntu had searchable application menus 10 years ago, which were awesome and worked for just about any program, and then dropped them when they abandoned Unity. And neither KDE not Gnome thought to bring them back. In stead, many apps have since dropped application menus entirely, in favour of... some mishmash of icons and ad hoc menu buttons?
Also, even in the post-LLM era, building a decent GUI app is a lot more work than building a decent terminal app.
Another factor is the lack of a good cross-platform GUI toolkit (by which I mean one that (a) doesn't feel out-of-place and jarring on any platform and (b) doesn't turn a 50K app into a 1GB download.)
Between that and the level of complexity of modern GUI toolkits - and the size of their dependency trees - distribution of a GUI app is a much bigger headache than distributing a terminal app.
Graphical applications are great if your workflow mirrors the workflow that the GUI was designed for. However if your workflow differs then you’ll often be fighting the GUI.
Think of it like different types of programming languages. Some are more suited on different types of problems than others.
For me, my workflow is about composing and gluing different processes together rather than using a standard defined tool repeatedly in the same way as that tools UI was originally designed. So the CLI is ideally suited for me in all the areas where a GUI would be high friction.
Terminals are text. Text adds features missing from gui namely:
* Ad Hoc
requirements change and terminal gives ultimate empty workbench flexibility. awesome for tasks you never new you had until that moment.
* Precision
run precisely what you want, when you want it. you are not constrained by gui UX limits.
* Pipeline
cat file.txt | perl/awk/sed/jq | tee output.result
* Equal Status
everything is text so you can combine clipboard, files, netcat output, curl output and then you can transform (above) and save. whatever you like in whatever form you like, named whatever you like.
Why? There is huge compatibility layer build on top of this and changing even these minor things will break stuff in places you do not expect. Want a fancy terminal? Install another one. By default most allow changing to many terminal formats. Break things to move forward is fun when it's not your problem to solve down the line.
If any end users actually cared about terminal/TUI apps, there would be modern APIs for whatever they want.
Since this is really just a legacy system operator monk / retrocool interface, they spend years debating ancient DEC theology.
It's a shame to see you get downvoted (presumably because you don't cite any evidence for your assertions). As a counter-point, I will give the oft-quoted-by-me 1990s promotional video of the use of IBM CallPath on an AS/400 which should get you all misty-eyed https://youtu.be/5pY6Xxptp9A?t=2058
Enjoy.