review/update hledger-ui theme names/selection

[simonmichael]

Related to #2167: I find the existing theme names a bit unclear. Here are my notes:

• 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 ?
• greenterm: shows monochrome green text on black background. Rename to greenonblack ?
• terminal: shows monochrome text using the terminal's current foreground/background colours. Is there a clearer name for this - minimal, transparent, mono.. ?
• dark (added by feat: ui: Add a dark theme #2167): shows dark gray text on black background, and a little colour for selection and negatives.

[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); 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.

• I'm fairly sure it's only the 4-bit colours and the greyscale ramp that are typically overriden by users who specify custom palettes in terminals. I just tried cycling through the palette options in gnome-terminal whilst watching the output of 256colors2.pl and only the 0-7 indexed "system colours" and grayscale ramp changed, not the colour cube (=8 bit)

[jmtd]

@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]

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

[jmtd]

@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: jmtd@48ddc42

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

[jmtd]

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.

[jmtd]

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):

[jmtd]

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.

[simonmichael]

Thanks for your explorations @jmtd!