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.

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.

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.

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

I’m concerned not everyone have their base colors set sensibly - as in “there’s no guarantee the base garish RGB green is green on this machine”. Maybe the right thing would be to put the color closest to a base color on the corresponding corner of the RGB cube, but that’s also not ideal - I have had terminal palettes that were all green or all orange/red, or the green/yellow of EL displays.

Maybe applying the saturation of the base set across all the generated palette would also work.

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.

[1] https://github.com/termstandard/colors

The word “should” is way too strong. It’s ultimately just a personal preference. For me I would prefer a two-tier approach.

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.

Oddly enough, I'm colorblind and I have had the worst time with color schemes. Many are completely unreadable and lack sufficient contrast. Others I just don't like

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

Sounds like I should try this together with ametameric, which I've been using since I have protanomaly

[0] https://ctx.graphics/terminal/ametameric/

The problem with this change is that it breaks setups for people who have already adjusted their color schemes to work with the 256-color palette as it is. It's now essentially double-adjusted.

(…and people wonder why I use gvim rather than vim…)

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

I see TFA mentions Solarized. I've been using Solarized light for longer than I can remember, even on Windows where I can (eg VSCode), and it goes a long way to making my eyes happy. I share the irritation with dark blue on black and can't stand dark mode (maybe I'm now old and no longer 31337 ... alas ...)

For my ncurses brothers, saw this but have not used yet: https://github.com/dankamongmen/notcurses

For my plan9 brothers: one day we will have a new acme, written in common lisp and displaying all the correct colors, and lo it will be glorious.

We should define a set of base colors for terminal apps that are used for themes so that we have a common set of colors for all term apps. Text, background, borders, hilight, muted then let the terminal set its theme.

Wild, potentially stupid thought: why couldn't a terminal let users supply a user.css like browsers? They'd only have to support the small subset of text styles.

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.

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.

This new palette should be behind a new control code, that should sort out the issue of opting in.

Should call it Super Terminal Entertainment System.

And this is why we have the Tc extension that terminals must implement now: I just use the 24 bit value I want directly.

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.

Nice to see Ghostty implemented it already. Feature-packed with sane defaults.

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.

seems this is implemented in latest iTerm2 commit https://github.com/gnachman/iTerm2/commit/39bafa8d6651865951...

> If you've spent much time in the terminal, you've probably set a custom base16 theme.

Hmm, I suspect that almost everyone who works in the terminal has never done this. I don’t really care what the colors look like, beyond choosing between whatever built in themes my terminal has. Is this really the minority experience?

Agree, and I love how concise, yet persuasive and practical this proposal is.

A key critique

The article is well argued and well written, as far as I’m concerned.

What’s needed if you really want adoption is to define a term; something like 256-ex for extended. Or whatever. But folks and apps need to be able to say; we’ve implemented or we support 256-ex. Without this label is hard to drive adoption.

The heartbleed thing from a few years back best taught me this.

Good luck I hope to see broad adoption it’s a great idea.

Give it a name, better yet move the copy onto a website with the same name also and a little icon folks can add to their website if they implement this k to their terminal app.

> 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

Harsh truth for Unix:

- A shell is not a terminal.

- Rc it's simpler than sh.

- You can totally put shells under graphical windows as in 9front

- You can do a better Unix than Unix itself while ditching out for good the VT220 interface

- Serial terminals aren't a thing under rio(9)

[flagged]

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.