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.

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

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.

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.

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

It’s been a fairly decent stop gap measure. I use tinted shell to switch between color schemes.

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.

> 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

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

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

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

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.

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.

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?

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.

Damn if only there was some other system that could be operating with that in mind

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

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?

Since this is really just a legacy system operator monk / retrocool interface, they spend years debating ancient DEC theology.

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.