Live data from Hacker News

Terminals should generate the 256-color palette

gist.github.com

141–150 of 212 posts

Re: Terminals should generate the 256-color palette

#142
post #74

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

> From what I know all modern terminal emulators in all operating systems support it now.

urxvt prominently doesn't (fully)

Re: Terminals should generate the 256-color palette

#143
post #32
post #21

Earlier quoted context omitted.

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

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.

Not just me then? My "dark blue" is always a kind of pale washed-out-bluey-grey because of that.

Re: Terminals should generate the 256-color palette

#144
post #63

Earlier quoted context omitted.

I know UNIX since being introduced to it via Xenix in 1992 thereabouts, and never found a use for tmux. More so, I use the terminal as strictly necessary and nothing more.

I don't want "a terminal", I want a command based interface combined with being able to use the same set of tools/commands on all the files I interact with. Like, it gets taken for granted, but being able to literally grep my html file, my program source and my readme file, instead of having to open a separate gui program and using its bespoke seach menu feature, is really, really nice. There are downsides of course,…

Thankfully Xerox PARC has an answer for that across Smalltalk, Interlisp-D, XDE, and Cedar, and copied to certain extent in modern programming languages, REPL environments and notebooks.

Augmented nowadays with agent environments and tools in IDEs, which can even be voice controlled.

Re: Terminals should generate the 256-color palette

#145
post #58

Earlier quoted context omitted.

Unix downvoters should have a look on 9front (the most featureful/supported plan9 fork out there) in order to realize that you can follow the Unix philosophy (even more than OpenBSD itself) tossing the VT100 emulators to the legacy 'vt' emulator if you want somehow use ancient software (or SSH) while setting actual graphical windows with the shell running inside with no terminals at all. No more damn control codes me…

(I didn't downvote you.) Plan 9 made some really cool design decisions, and I keep looking for places to use 9P. I also believe that Plan 9, as an artifact of its era, bet too heavily on the mouse and pixel-mapped graphics. Text, character-cell terminal emulation, and SSH won for good reasons. "GUI > terminal" is a separate matter from "Plan 9 > Unix". In some important ways, even text with hacky escape codes is more…

> I also believe that Plan 9, as an artifact of its era, bet too heavily on the mouse and pixel-mapped graphics. Text, character-cell terminal emulation, and SSH won for good reasons. "GUI > terminal" is a separate matter from "Plan 9 > Unix".

What era? That is exactly the workflow of everyone using macOS and Windows around here.

Connecting to cloud environemnts is also done via a mix of RDP, VNC, Web GUI based tooling, akin to a modern X Windows replacement.

Re: Terminals should generate the 256-color palette

#146
post #61

Earlier quoted context omitted.

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

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.

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

Re: Terminals should generate the 256-color palette

#147

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…

> Many are completely unreadable and lack sufficient contrast.

I am not colorblind, and have the same experience. It's made worse by the fact that different apps use colors differently, so if I find a theme that works well for some clis and tuis, there will be others that will have unreadably low contrast with the default theme. So I have to tweak the colorscheme for each application as well.

Re: Terminals should generate the 256-color palette

#148
post #126

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

The OP specifically says why that isn't ideal: The mainstream solution is to use truecolor and gain access to 16 million colors. But there are drawbacks: Each truecolor program needs its own theme configuration. Changing your color scheme means editing multiple config files. Light/dark switching requires explicit support from program maintainers. Truecolor escape codes are longer and slower to parse. Fewer terminals…

> Each truecolor program needs its own theme configuration.

Yes, but programs that need more than 16 colors are already often doing this.

> Changing your color scheme means editing multiple config files.

Already has been implemented at least several times over.

> Light/dark switching requires explicit support from program maintainers.

Yes, we have an escape sequence to ask the terminal to ask the OS for this. Most programs that need to care about this already use it.

> Truecolor escape codes are longer and slower to parse.

Not in a way that matters. It only shows up on torture test benchmarks on especially slow parsers. It wouldn't effect normal usage even on a terminal running on some tiny SBC.

> Fewer terminals support truecolor.

XTerm itself, rxvt, iterm2, Alacritty, Wez, Kitty, Ghostty, wt/modern conhost, mintty, st, everything that uses libvte, everything that uses libvterm (such as neovim's built in term), emacs's term, asciinema; tmux, screen, dvtm safely handle them; the linux console snaps it to the nearest 256 color; iterm.app, the original garbage osx one, is the only major term I can think of that does not handle it.

Re: Terminals should generate the 256-color palette

#149
post #108

Earlier quoted context omitted.

It would be much better if application developers (and web developers, too) -only- had access to semantic color labels like TEXT, BACKGROUND, ERROR, WARNING, INFO, HIGHLIGHT, and so on, rather than red, yellow, blue, green, black. I don’t want my applications to decide “this element must be red text on green background.” I want my applications to annotate the UI with things like “warning message” and “title.”

That could be done with a few influential terminal emulators adopting a consensus extension to ISO8613-6, like this: ESC[38:99: ‹purpose› m for foreground, ESC[48:99: ‹purpose› m for background. e.g. Foreground Background Purpose ----------- ----------- ------- ESC[38:99:0m ESC[48:99:0m normal ( same as ESC[39m and ESC[49m ) ESC[38:99:1m ESC[48:99:1m emphasise ESC[38:99:2m ESC[48:99:2m de-emphasise ESC[38:99:3m ESC[4…

"selected" and "highlighted" would also be useful

Re: Terminals should generate the 256-color palette

#150
post #32
post #21

Earlier quoted context omitted.

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

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.

And I filed a PR because an author used yellow and hadn’t assigned orange to any purpose, which is actually legible on a white terminal where yellow never is.
Post reply on HN