Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terminals should generate the 256-color palette

gist.github.com

Post reply on HN
Print view View original

11–20 of 212 posts

Re: Terminals should generate the 256-color palette

#11

Post by consp »

stackghost wrote: post #10

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…

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.

Re: Terminals should generate the 256-color palette

#12

Post by johncoltrane »

jauntywundrkind wrote: post #7
johncoltrane wrote: post #5

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 t…

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…

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.

Re: Terminals should generate the 256-color palette

#13

Post by vanviegen »

stackghost wrote: post #10

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…

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.

Re: Terminals should generate the 256-color palette

#14

Post by worthless-trash »

King-Aaron wrote: post #2

> 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.

Re: Terminals should generate the 256-color palette

#15

Post by gzread »

worthless-trash wrote: post #14
King-Aaron wrote: post #2

> 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.

Re: Terminals should generate the 256-color palette

#16

Post by Sardtok »

jimrandomh wrote: post #3

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 ha…

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.

Re: Terminals should generate the 256-color palette

#19

Post by lloeki »

johncoltrane wrote: post #5

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 t…

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