upvote
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
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
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
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
"selected" and "highlighted" would also be useful
reply