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

101–110 of 212 posts

Re: Terminals should generate the 256-color palette

#101

Post by johncoltrane »

tambourine_man wrote: post #82
johncoltrane wrote: post #52

Earlier quoted context omitted.

First, I make third-party Vim colorschemes, not app. People install my colorschemes because they like the colors, not because I'm a monster with a gun pointed at their face. No one is harmed. No one is forced to do anything they don't want. Outside of my text editor, where colors matter a lot to me for syntax highlighting, I'm definitely in the NO_COLORS camp (and in the NO_EMOJI camp, nowadays). > Color usage in the…

Can you link to your Vim colorschemes? I have a light and a dark one that I hacked over the years but I'm always looking for new ones.

My latest, "zaibatsu" is bundled with Vim.

- Apprentice, a low-contrast colorscheme I made years ago and used for a long time: https://github.com/romainl/Apprentice.

- Malotru, my curent colorscheme, more contrasted: https://github.com/romainl/vim-malotru.

- Dichromatic, for colorblind users: https://github.com/romainl/vim-dichromatic.

- Bruin, which only uses typography: https://git.sr.ht/~romainl/vim-bruin

Re: Terminals should generate the 256-color palette

#102

Post by anthk »

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)

Re: Terminals should generate the 256-color palette

#103

Post by mort96 »

johncoltrane wrote: post #99
jve wrote: post #95

Earlier quoted context omitted.

Is there a human that can read that dark blue on black or is it just us who has their eyes wired differently? I have to select that text to change the background to read it.

No one can and people have been complaining about it for decades. But there is no standard or standard body anywhere for terminal colors so there is no obvious way to improve this situation. And no urgency either, because all terminal emulators allow users to customize the palette anyway.

If I was the maintainer of a terminal emulator, I would see a quite obvious way to improve the situation for my users: change the default colors so that dark blue is brighter.

There's no obvious way to unilaterally improve the situation across the whole ecosystem, that's true. But I don't understand why individual terminal emulator maintainers don't fix it for their users.

Re: Terminals should generate the 256-color palette

#104

Post by tambourine_man »

johncoltrane wrote: post #101
tambourine_man wrote: post #82

Earlier quoted context omitted.

Can you link to your Vim colorschemes? I have a light and a dark one that I hacked over the years but I'm always looking for new ones.

My latest, "zaibatsu" is bundled with Vim. - Apprentice, a low-contrast colorscheme I made years ago and used for a long time: https://github.com/romainl/Apprentice . - Malotru, my curent colorscheme, more contrasted: https://github.com/romainl/vim-malotru . - Dichromatic, for colorblind users: https://github.com/romainl/vim-dichromatic . - Bruin, which only uses typography: https://git.sr.ht/~romainl/vim-bruin

Nice work. Apprentice looks great. Thanks for the links.

Re: Terminals should generate the 256-color palette

#105

Post by [deleted] »

johncoltrane wrote: post #12
jauntywundrkind wrote: post #7

Earlier quoted context omitted.

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

[deleted]

Re: Terminals should generate the 256-color palette

#106

Post by johncoltrane »

mort96 wrote: post #103
johncoltrane wrote: post #99

Earlier quoted context omitted.

No one can and people have been complaining about it for decades. But there is no standard or standard body anywhere for terminal colors so there is no obvious way to improve this situation. And no urgency either, because all terminal emulators allow users to customize the palette anyway.

If I was the maintainer of a terminal emulator, I would see a quite obvious way to improve the situation for my users: change the default colors so that dark blue is brighter. There's no obvious way to unilaterally improve the situation across the whole ecosystem, that's true. But I don't understand why individual terminal emulator maintainers don't fix it for their users.

Because it means making choices, breaking assumptions, etc.. They have made it user-customizable so they don't have to go through all that.

FWIW, the current de-facto standard is set by xterm. Here is a relevant excerpt of its source code:

    ! Disclaimer: there are no standard colors used in terminal emulation.
    !
    ! The choice for color4 and color12 is a tradeoff between contrast, depending
    ! on whether they are used for text or backgrounds.  Note that either color4 or
    ! color12 would be used for text, while only color4 would be used for a
    ! background.  These are treated specially, since the luminosity of blue is
    ! only about half that of red/green, and is typically not accounted for in the
    ! RGB scheme.
    !
    ! Blue text on a black background should be readable.
    ! Blue backgrounds should not be "too" bright.
    !
    ! Originally color4/color12 were set to the names blue3/blue
    !*VT100*color4: blue3
    !*VT100*color12: blue
    !
    ! They are from rgb.txt respectively:
    !  0   0 205  blue3
    !  0   0 255  blue
    ! However, blue3 is not readable on a black background.
    !
    ! Another choice was from the Debian settings:
    !*VT100*color4: DodgerBlue1
    !*VT100*color12: SteelBlue1
    !
    ! From rgb.txt:
    ! 30 144 255  DodgerBlue1
    ! 99 184 255  SteelBlue1
    !
    ! Some users object to this choice because the background (color4) is brighter
    ! than they are accustomed.  Others point out that the different weights for
    ! the red/green components make it appear to be not really blue.  Finally, it
    ! provides poor contrast against color13 and color14.
    !
    ! The current choice uses equal weights for red/green (effectively adding a
    ! gray to the result).  It is brighter than the original choice, and provides
    ! more contrast between color12 and color13, color14 than SteelBlue1 did.
    ! Contrast of color4 against black is slightly improved over the original.
    !
    ! Some refinement is certainly possible (you are welcome to try) -TD
Make that what you will :-).

Re: Terminals should generate the 256-color palette

#107

Post by skydhash »

robinsonb5 wrote: post #25
vanviegen wrote: post #13

Earlier quoted context omitted.

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

Another factor is the lack of a good cross-platform GUI toolkit (by which I mean one that (a) doesn't feel out-of-place and jarring on any platform and (b) doesn't turn a 50K app into a 1GB download.) Between that and the level of complexity of modern GUI toolkits - and the size of their dependency trees - distribution of a GUI app is a much bigger headache than distributing a terminal app.

Make the core feature of your app a library, then write different interfaces according to the targeted platforms.

Re: Terminals should generate the 256-color palette

#108

Post by kps »

ryandrake wrote: post #86
johncoltrane wrote: post #52

Earlier quoted context omitted.

First, I make third-party Vim colorschemes, not app. People install my colorschemes because they like the colors, not because I'm a monster with a gun pointed at their face. No one is harmed. No one is forced to do anything they don't want. Outside of my text editor, where colors matter a lot to me for syntax highlighting, I'm definitely in the NO_COLORS camp (and in the NO_EMOJI camp, nowadays). > Color usage in the…

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[48:99:3m   error
    ESC[38:99:4m    ESC[48:99:4m   warning
    ESC[38:99:5m    ESC[48:99:5m   caution
    ESC[38:99:6m    ESC[48:99:6m   notice
Then people (themes) could easily choose foreground colour or background highlighting for particular roles. Some terminal emulators might also choose to configure other stylistic choices like bold, italic, etc.

(I believe ISO8613-6 defines sub-modes 0 through 5 (te;db), with 2 (rgb) and 5 (256-color indexed) being most widely implemented. But some terminals historically mess up : and ; in CSI sequences, and I know at least one would interpret ESC[38:6:1m as ESC[6;1m (blinking bold!), so here I pick 99 (ECMA-48 defines modes up to 65).)

Re: Terminals should generate the 256-color palette

#109

Post by SAI_Peregrinus »

johncoltrane wrote: post #99
jve wrote: post #95

Earlier quoted context omitted.

Is there a human that can read that dark blue on black or is it just us who has their eyes wired differently? I have to select that text to change the background to read it.

No one can and people have been complaining about it for decades. But there is no standard or standard body anywhere for terminal colors so there is no obvious way to improve this situation. And no urgency either, because all terminal emulators allow users to customize the palette anyway.

There are fewer blue cones in the fovea centralis than there are in the surrounding parts of the macula, so humans can't resolve details as well in blue light.

Re: Terminals should generate the 256-color palette

#110

Post by ux266478 »

robinsonb5 wrote: post #46
iberator wrote: post #43

Earlier quoted context omitted.

there is TCL-TK. :) Super easy to use, fast, almost zero ram usage and battle tested for 2 decades.

"Equally jarring and out-of-place on all platforms" isn't quite what I asked for, but I guess it's the next best thing! ;)

That hasn't been true for a while, it's easily the best of the bunch at this point. It's also always been trivial to change, which can't be said of the others.
Post reply on HN