Expose ANSI themes

[willmcgugan]

In Textual we convert ANSI themes into truecolor themes. We always assume DIMMED_MONOKAI. We should expose that to the dev, and provide 2 terminal themes for light and dark mode.

Suggestions for interface: Two reactives on App that take a Rich TerminalTheme instance: dark_terminal_theme and light_terminal_theme. Setting either of these would do a full CSS refresh.

[darrenburns]

I'm not 100% sure I'm following what this is. What is the ANSI theme and how does it relate to the terminal theme/the colours from the design system?

[darrenburns]

I'm actually wondering if a developer explicitly specifies ANSI "red" in their code, should we really be modifying that? I actually think it would be astonishing, and a little bit annoying - I think @davep's confusion at standup shows that it's surprising.

I understand if we have to modify it to a hex code so we can blend etc, but I'm wondering if it should just be a direct mapping to the ANSI colours (e.g. red -> #ff0000).

[willmcgugan]

It's covered in the FAQ https://textual.textualize.io/FAQ/#why-doesnt-textual-support-ansi-themes

The upshot is that if we don't replace the ANSI colors with RGB, Textual apps may look awful on some user's terminals.

[darrenburns]

Yeah, I'm aware of that - I think my first paragraph was poorly worded.

Just to be clear I'm suggesting replacing red with #ff0000, so it's not impacted at all by the terminal emulator theme and it guarantees consistency. It would look the same on every terminal, and when a developer specifies red, they get #ff0000 every time.

I think changing the actual colour is where it becomes surprising, i.e. if I write red and I receive some pink/purple/red mixture from Dimmed Monokai on every terminal, then I'm really surprised. If I write red and I receive #ff0000, then it's what I would expect.

If I want the pink/purple/red from Dimmed Monokai, shouldn't I expect as a developer to have to just write out the hex code?

[willmcgugan]

The thing is these ansi styles can come from a variety of sources. They can come from Text.from_ansi, or from Rich renderables where [red] would generate an ANSI red. The user is unlikely to be expecting #ff0000 there.

This only impacts Text and other Rich renderables. If you specify "red" in the CSS you will get a consistent red, as taken from _color_constants.py.

[darrenburns]

The user is unlikely to be expecting #ff0000 there.

I don't understand this at all to be honest. I can't see how they would ever be expecting a conversion here given that we don't respect terminal emulator themes. There are 3 options:

• red -> the user's terminal ANSI red (ruled out as explained in FAQ)
• red -> #ff0000
• red -> some other colour from an attribute

I can honestly say that when I write red in a Text object while in Textual, I never even considered that it might be converted to something other than #ff0000. Just having it behave differently from CSS red is awkward enough.

In Textual, when I write red and expect red, just like in CSS. It's far less surprising than specifying red and getting pink/purple 😄

[willmcgugan]

Why #ff0000 though? Because red doesn't equate to #ff0000 on most terminals (if you scroll down to the color table on this page https://en.wikipedia.org/wiki/ANSI_escape_code, you can see red is only that saturated on Windows).

The ansi colors and CSS colors are different domains where the colors are different. I know its not ideal. In the future I would like to have some non-Rich Text equivalent that uses the CSS colors, but I don't see any way around having some kind of ANSI theme concept.

[darrenburns]

Why #ff0000 though?
...
The ansi colors and CSS colors are different domains where the colors are different.

Because having it just match CSS is the least astonishing option. It also feels like we're telling them we know better than them - "you think you want red, but you actually want something defined by us".

The app developer can see exactly what end users will see, so where's the benefit in "correcting" their colour choices for them?

Telling users "if you write red here it means #ff0000, but if you write red there it's something totally different" is awful developer experience.

red doesn't equate to #ff0000 on most terminals

Textual doesn't respect what red equates to on any terminal anyway, by choice 🤷‍♂

The themes also are completely unrelated to the current Textual design system, and are only going to change a subset of the things on screen in a way that's totally inconsistent with the design system.

---

It's extra complexity that I genuinely don't see any benefit to (if red looks terrible, pick a different colour). The overall result of adding this stuff is a small number of colours, but only some of them, will change in your apps, in a way that is inconsistent with the other styling system we have. Who does this benefit?

It would also add two reactives to App that I'm 100% sure I would expect to change the whole theme of Textual (everything I see on screen).

I don't see any way around having some kind of ANSI theme concept.

Could this kind of functionality not belong in Textual's theme system? If I set app.theme = "monokai", then all the CSS vars $primary etc. change to Monokai colours AND the definition of "ansi red" changes to Monokai's red?

[github-actions]

Don't forget to star the repository!

Follow @textualizeio for Textual updates.