5 ms·

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 viole

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.

jauntywundrkind 8mo ago
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.
- johncoltrane 8mo ago
  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.
  - deleted 8mo ago
    [deleted]
  - wredcoll 8mo ago
    I feel like any term that had this feature would also fully support truecolor, which suggests a way forward.
- duskdozer 8mo ago
  >Apps & designers want their own brand identity This is the main issue as I see it. Obviously I'd prefer to need to customize less, but as long as I have the option to override the defaults, I don't care much about what those defaults are. But the concept of "branding" flies right in the face of this.
lloeki 8mo ago
Terminals like iTerm2 have had a Minimum Contrast for a while that messes with (foreground) colours, sometimes very badly.
- shimman 8mo ago
  For far too long I'm ashamed to admit, I would use vim with the adventure time theme on iterm2. Looking at it now I'm shocked my eyes didn't bleed more. I think the worst part was that visual mode was neon yellow bold text with neon pink bg. Relying on visual mode quite a bit while using vim I was self inoculating my subconscious with stills of a poor Jackson Pollock imitator while on multiple different amphetamines. Hopefully I find out my resistance soon.
hnlmorg 8mo ago
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.
- ffaser5gxlsll 8mo ago
  > 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.
- mort96 8mo ago
  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.
  - kevin_thibedeau 8mo ago
    Most of them are emulating the EGA/VGA palette which was a regression from the CGA terminal colors. https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-palette/ https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...
ryan-c 8mo ago
There are escape codes that can re-define palette entries. Usually including the 16-255 range.
- johncoltrane 8mo ago
  Yes, I know that (see the venerable https://github.com/trapd00r/colorcoke 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.
vova_hn2 8mo ago
I'm sorry, but I find this mentality from app developers extremely annoying. 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.
- johncoltrane 8mo ago
  I'm not an app developper. I make third-party colorschemes for Vim, which I assume are downloaded, installed, and used by people on their own volition, after they have looked at, and liked, the screenshots. Moreover, I take great care to make sure they are still usable in 16c, within reason. 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.
  - poly2it 8mo ago
    Why not truecolor if you want true colours?
    - johncoltrane 8mo ago
      I don't want true colours. I want what I already have, 16-255, to stay reliable in the future.
      - 8mo ago
donatj 8mo ago
> provide a [...] consistent experience 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.
- johncoltrane 8mo ago
  First, I make third-party Vim colorschemes, not app. People install my colorschemes because they like the colors, not because I'm a monster with a gun pointed at their face. No one is harmed. No one is forced to do anything they don't want. 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.
  - tambourine_man 8mo ago
    Can you link to your Vim colorschemes? I have a light and a dark one that I hacked over the years but I'm always looking for new ones.
    - johncoltrane 8mo ago
      My latest, "zaibatsu" is bundled with Vim. - Apprentice, a low-contrast colorscheme I made years ago and used for a long time: https://github.com/romainl/Apprentice https://github.com/romainl/Apprentice. - Malotru, my curent colorscheme, more contrasted: https://github.com/romainl/vim-malotru https://github.com/romainl/vim-malotru. - Dichromatic, for colorblind users: https://github.com/romainl/vim-dichromatic https://github.com/romainl/vim-dichromatic. - Bruin, which only uses typography: https://git.sr.ht/~romainl/vim-bruin https://git.sr.ht/~romainl/vim-bruin
tasuki 8mo ago
> which gives us a very high level of confidence that 146 will be a muted violet 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.
- johncoltrane 8mo ago
  I make Vim colorschemes so I'm fully in control of all those aspects. If I decide I want a given token in muted violet it is because I know that it will works well with the background… that I have defined myself. 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.
  - pkulak 8mo ago
    > I make Vim colorschemes 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.
tambourine_man 8mo ago
I think it's an interesting idea, but should be set as an option and default to off, for the reason you describe. 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.
Gormo 8mo ago
> and consistent experience across the widest range of terminal emulators. 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.
- johncoltrane 8mo ago
  No, because I don't develop programs. I make third-party Vim colorschemes that users install because they like the colors. There is no impending happening, here.
lucideer 8mo ago
> This is very useful for colorscheme developers 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).

jauntywundrkind 8mo ago

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.

johncoltrane 8mo ago
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.
- deleted 8mo ago
  [deleted]
- wredcoll 8mo ago
  I feel like any term that had this feature would also fully support truecolor, which suggests a way forward.
duskdozer 8mo ago
>Apps & designers want their own brand identity This is the main issue as I see it. Obviously I'd prefer to need to customize less, but as long as I have the option to override the defaults, I don't care much about what those defaults are. But the concept of "branding" flies right in the face of this.

lloeki 8mo ago

Terminals like iTerm2 have had a Minimum Contrast for a while that messes with (foreground) colours, sometimes very badly.

shimman 8mo ago
For far too long I'm ashamed to admit, I would use vim with the adventure time theme on iterm2. Looking at it now I'm shocked my eyes didn't bleed more. I think the worst part was that visual mode was neon yellow bold text with neon pink bg. Relying on visual mode quite a bit while using vim I was self inoculating my subconscious with stills of a poor Jackson Pollock imitator while on multiple different amphetamines. Hopefully I find out my resistance soon.

hnlmorg 8mo ago

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.

ffaser5gxlsll 8mo ago
> 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.
mort96 8mo ago
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.
- kevin_thibedeau 8mo ago
  Most of them are emulating the EGA/VGA palette which was a regression from the CGA terminal colors. https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-palette/ https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...

ryan-c 8mo ago

There are escape codes that can re-define palette entries. Usually including the 16-255 range.

johncoltrane 8mo ago
Yes, I know that (see the venerable https://github.com/trapd00r/colorcoke 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.

vova_hn2 8mo ago

I'm sorry, but I find this mentality from app developers extremely annoying. 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.

johncoltrane 8mo ago
I'm not an app developper. I make third-party colorschemes for Vim, which I assume are downloaded, installed, and used by people on their own volition, after they have looked at, and liked, the screenshots. Moreover, I take great care to make sure they are still usable in 16c, within reason. 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.
- poly2it 8mo ago
  Why not truecolor if you want true colours?
  - johncoltrane 8mo ago
    I don't want true colours. I want what I already have, 16-255, to stay reliable in the future.
    - 8mo ago

donatj 8mo ago

> provide a [...] consistent experience 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.

johncoltrane 8mo ago
First, I make third-party Vim colorschemes, not app. People install my colorschemes because they like the colors, not because I'm a monster with a gun pointed at their face. No one is harmed. No one is forced to do anything they don't want. 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.
- tambourine_man 8mo ago
  Can you link to your Vim colorschemes? I have a light and a dark one that I hacked over the years but I'm always looking for new ones.
  - johncoltrane 8mo ago
    My latest, "zaibatsu" is bundled with Vim. - Apprentice, a low-contrast colorscheme I made years ago and used for a long time: https://github.com/romainl/Apprentice https://github.com/romainl/Apprentice. - Malotru, my curent colorscheme, more contrasted: https://github.com/romainl/vim-malotru https://github.com/romainl/vim-malotru. - Dichromatic, for colorblind users: https://github.com/romainl/vim-dichromatic https://github.com/romainl/vim-dichromatic. - Bruin, which only uses typography: https://git.sr.ht/~romainl/vim-bruin https://git.sr.ht/~romainl/vim-bruin

tasuki 8mo ago

> which gives us a very high level of confidence that 146 will be a muted violet 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.

johncoltrane 8mo ago
I make Vim colorschemes so I'm fully in control of all those aspects. If I decide I want a given token in muted violet it is because I know that it will works well with the background… that I have defined myself. 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.
- pkulak 8mo ago
  > I make Vim colorschemes 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.

tambourine_man 8mo ago

I think it's an interesting idea, but should be set as an option and default to off, for the reason you describe. 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.

Gormo 8mo ago

> and consistent experience across the widest range of terminal emulators. 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.

johncoltrane 8mo ago
No, because I don't develop programs. I make third-party Vim colorschemes that users install because they like the colors. There is no impending happening, here.

lucideer 8mo ago

> This is very useful for colorscheme developers 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).