alt Hacker NewsTerminals should generate the 256-color palette
Comments
My streaming markdown renderer does something like that https://github.com/day50-dev/Streamdown
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
I had exactly this thought!
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.
Just use direct color mode (24bit, "true color")[1] and there will be no need for a palette.
> Fewer terminals support truecolor.
From what I know all modern terminal emulators in all operating systems support it now.
Color schemes voluntarily added by the user to an app like vim, great.
All the more reason for developers to keep the app itself responsive to the user’s environment by default.
Don’t bake in elaborate visual choices. It’s a usability thing first and a style thing somewhere much farther down the list.
Keep it simple from the factory. Don’t get in the way of customization. Let the user’s environment do the work of adapting it to the user.
Really interested in this for cargo/rustc. We run into issues where we need one or two more colors but all that is left after going for the basic semantic colors is magenta (odd choice), and black and white (not safe without inspecting the theme).
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.
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.
This new palette should be behind a new control code, that should sort out the issue of opting in.
Sounds like I should try this together with ametameric, which I've been using since I have protanomaly
Kde has their own palette, and I hate it, the colours are all wrong, and the scheme is fugly... I usually set it to "Linux default" and hope its good enough to read
seems this is implemented in latest iTerm2 commit https://github.com/gnachman/iTerm2/commit/39bafa8d6651865951...
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.
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.
I’d also add a quantization slider that would quantize the in-between colors to less than 256 different colors; in the extreme position to just the 16 colors.
> 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
Agree, and I love how concise, yet persuasive and practical this proposal is.
test
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?
Terminals should be able to show images, so you could run Jupyter notebooks in them.
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.
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.
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.