upvote

points

by johncoltrane13 hours ago |
comments
upvoteby ryandrake11 hours ago|
next
[-]
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.”

reply
upvoteby kps10 hours ago|
parent|
next
[-]
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).)

reply
upvoteby zzo38computer3 hours ago|
parent|
next
[-]
I like this idea, although I think that they should be only one code, which might program both the foreground and background (and font styles if applicable), rather than separate codes for foreground and for background.
reply
upvoteby kps3 hours ago|
parent|
[-]
Yes, since this morning, I've thought a little more and agree. (I just finished replying to another reply.)

Anyone interested, ping me (address in profile) and encourage me to set up a repo to discuss and formulate a concrete proposal.

reply
upvoteby hnlmorg4 hours ago|
parent|
prev|
next
[-]
This is a fantastic idea!

I’m working on a terminal emulator. It’s not big like Ghostty but this is something I might adopt

reply
upvoteby kps3 hours ago|
parent|
[-]
After thinking about it a bit more, I think the specific details of that (i.e. inventing an extended colour mode) are not ideal.

One alternative: Assign semantics to colour indexes above 256.

Both of those have the disadvantage that they separate foreground and background colour, but a user really wants a combined semantic presentation. For instance, a user might want a warning message to be black text on a yellow background, and not have to rely on the program remembering to set both foreground and background to ‘warning’ colour.

So another possibility is just to invent new SGR numbers, e.g.

    Control         Purpose
    ------------    -------
    CSI 2 0 0 m    normal (undoes any CSI 1 x x m)
    CSI 2 0 1 m    emphasise
    CSI 2 0 2 m    de-emphasise
    CSI 2 0 3 m    error
    CSI 2 0 4 m    warning
    CSI 2 0 5 m    caution
    CSI 2 0 6 m    notice
    ⋮
Then the user can configure those as they please with any combination of foreground, background, weight, slant, etc.

I'm now thinking about writing up pros and cons of alternatives.

reply
upvoteby planckscnst6 hours ago|
parent|
prev|
[-]
"selected" and "highlighted" would also be useful
reply
upvoteby johncoltrane11 hours ago|
parent|
prev|
[-]
I would really love to have that, too, on every "platform" I have to work on.
reply
upvoteby makapuf6 hours ago|
prev|
next
[-]
My proposal would be to define a set of intents for 0-15 with sensible defaults and let terminal themes assign any color they would like to those. 0 would be background, 7 for foreground , 1 for highlight, 3 for titles, 4 for frames and from there work on backgrounds also..
reply
upvoteby tambourine_man11 hours ago|
prev|
[-]
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.
reply
upvoteby johncoltrane10 hours ago|
parent|
next
[-]
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

reply
upvoteby tambourine_man10 hours ago|
parent|
[-]
Nice work. Apprentice looks great. Thanks for the links.
reply
upvoteby wredcoll8 hours ago|
parent|
prev|
[-]
Can you share your light one? I've never been able to find a white background scheme I actually love, rather than tolerate...
reply
upvoteby johncoltrane8 hours ago|
parent|
[-]
I prefer my background dark so light colorschemes are not really an area I've explored seriously. Also, dark colorschemes are much easier to design than light ones due to the disproportionate amount of light a white, say, background emits compared to the amount emitted by text. It dramatically reduces the number of colors you can use.

I have one here: https://github.com/romainl/vim-sweet16 but it is intentionally weird and essentially unmaintained.

reply
upvoteby wredcoll4 hours ago|
parent|
[-]
=[

We have many millenia of books using black text on a white background with various colors added, why are computer monitors all of a sudden so special and annoying

reply
upvoteby hnlmorg4 hours ago|
parent|
[-]
Because paper is naturally pale. So it would have been silly for people to colour them black.

And because monitors are giant light bulbs. So a large white background is harder on the eyes than black.

reply