Open simonmichael opened 7 months ago
It may be worth ensuring we have at least one theme that honours the user's terminal colour choices (i.e., a theme which, if they've got light-text-on-dark, so does the theme, and vice-versa); at least one defined in indexed colours (i.e. colours 0-7) which might be redefined by the user* ; and one or more that uses specific colour values (24 bit?) so it looks consistent no matter the terminal settings.
I'm not very experienced with Brick (yet) so I don't know whether it gives us sufficient control. I recently read this blog post -- I Just Wanted Emacs to Look Nice — Using 24-Bit Color in Terminals -- which was a nice summary of how this all works in Today's terminals.
256colors2.pl
and only the 0-7 indexed "system colours" and grayscale ramp changed, not the colour cube (=8 bit)@simonmichael :
greenterm: shows monochrome green text on black background. Rename to greenonblack ?
Sounds good.
@jmtd:
It may be worth ensuring we have at least one theme that honours the user's terminal colour choices (i.e., a theme which, if they've got light-text-on-dark, so does the theme, and vice-versa);
Of the current themes (including dark
), terminal
is the only one that does this. So I think that one should be kept around.
@simonmichael:
terminal: shows monochrome text using the terminal's current foreground/background colours. Is there a clearer name for this - minimal, transparent, mono.. ?
Perhaps a synonym or reference to the fact it delegates the colour decision to the terminal. I'll ponder on that.
Back to the default theme.
I think it makes sense for the default theme to set a static colour scheme (as it does). Except
@simonmichael :
But when run in a VS Code terminal, shows me a darkish gray background. Would be nice if it were more consistent, and then it could be renamed to light ?
I can't explain this but I wll try to reproduce it.
For dark
, I think it makes sense for it static too, i.e., always dark, no matter the terminal settings.
@jmtd
terminal Perhaps a synonym or reference to the fact it delegates the colour decision to the terminal. I'll ponder on that.
"inherit" is the best I've got so far.
@simonmichael:
default: normally shows me a light background and some colour. But when run in a VS Code terminal, shows me a darkish gray background. Would be nice if it were more consistent, and then it could be renamed to light ?
The colours currently used for themes are taken from the 4-bit palette (indexed colour), which are often different between terminals (and sometimes customised by users). To get consistent colour, a theme would need to swap to colours from a wider palette (Brick seems to support the 8-bit-ish 240-colour mode; we could define some colours using e.g. linearColor; although, a further caveat, we would have to be careful to pick from the 240 supported colours to get consistency; the others are mapped into those.)
This little hack fixes the default theme background colour, for example, even if I switch gnome-terminal
themes or palettes: https://github.com/jmtd/hledger/commit/48ddc42d02ebd038fc125488bfe9efefdfd17732
It'll be necessary to test Brick's fallback behavour when operating in a terminal which doesn't support 16-bit colour. (can probably be done in any modern terminal by faking TERM
)
I'll explore this a bit more
The fallback behaviour of Vty when using the 240-color palette with a terminal that does not support it is, sadly, not great; I was expecting (from reading the docs) an approximate mapping into the 4-bit space, but it just writes out in monochrome.
This is the 240 color palette via Vty in my terminal which supports it (kitty)
And here's the same program's output if the TERM is xterm-color (supports 4 bit but not the 8-bit-ish 240 colour palette):
I've pushed a WIP branch that redefines the default theme in terms of the fixed 240 palette. It's early-state, too early for a PR I think, but I'll keep poking at it.
Thanks for your explorations @jmtd!
Related to #2167: I find the existing theme names a bit unclear. Here are my notes: