4 ms·

You’re talking about technical aspects of colour support. Yeah, that requires a little bit of care, but it’s not what I’m talking about. I’m talking about how t

You’re talking about technical aspects of colour support. Yeah, that requires a little bit of care, but it’s not what I’m talking about. I’m talking about how the colour values are unreliable, so that even when you have your 256 colours or whatever, you should only use about three of them in any default configuration.

eesmith 4y ago
Which terminals are you concerned about? I can totally understand that support for (say) a Wyse WY60 may be lacking, and understand how the authors don't consider that to be an issue. It looks like you can style to the terminal capabilities, using https://rich.readthedocs.io/en/latest/reference/style.html https://rich.readthedocs.io/en/latest/reference/style.html .
- chrismorgan 4y ago
  Just what I said in my original comment: the colours are unreliable. Bold might change the colour or might be almost indistinguishable. Bright white might be higher contrast (on dark terminals) or zero contrast (on some light terminals). Blue might be easy to read (on most newer dark terminals) or very painful to read and almost invisible (on most older dark terminals). Yellow might be brighter than the default colour, or low contrast and not great to read. You just don’t know about any of this stuff unless you check it (which is possible in some terminals, but even then it’s a bit risky as a strategy). The technical aspects of colour support are fairly uninteresting. The inconsistency of the actual colours is the problem.
  - eesmith 4y ago
    > the colours are unreliable And as I asked in my followup, in which terminals ? In any case, my point was that once you checked them, it looks like Rich can handle the configuration, and you can set up a theme to use, and textualize will let you pass in a Rich configuration.
    - chrismorgan 4y ago
      > once you checked them You can’t guarantee that you can check them, and that’s the problem. I haven’t directly surveyed terminal support for the relevant OSC sequences (I wish someone would make a thorough terminal feature comparison—in theory terminfo databases would be part of this, but in practice the scheme is thoroughly broken), but from what I’ve heard I would expect a reasonably strong correlation between support for that and support for 24-bit colour. That is, you are unlikely to be able to check the colours on the very environments where you most need to. As far as static checking of terminal capabilities is concerned, I think it’s reasonable to say that everything’s completely broken by design there too. Everything builds upon the idea of a $TERM variable being right and terminfo databases having relevant entries and matching reality, and they’re just not. $TERM will be missing or wrong extremely often, and terminfo databases are regularly out of date, and if you try to use a “correct” value for $TERM you’ll often find various software (especially old software, but even new stuff sometimes) falls over, normally in the direction of claiming that your terminal is incapable of doing something that it is actually capable of. This got to be such a problem that $COLORTERM was introduced, which is more likely to describe the true capabilities of your terminal, but still not quite always even if it’s there, and much important software doesn’t look at it either. If you’re familiar with web history, it’s a similar sort of issue to what happened in the User-Agent header, and for similar reasons. So then, you’re left with maybe some notion of the terminal’s capabilities, and maybe the ability to find out what the colours actually are, but you can’t depend on either of these, and so you can’t in the general case depend on the values of any colours.
      - eesmith 4y ago
        > You can’t guarantee that you can check them, and that’s the problem. Understood. I misread your mention of "checking" as meaning for an organization which wants to deploy a TUI internally, where they can check all of the supported terminals. > That is, you are unlikely to be able to check the colours on the very environments where you most need to. Which terminals are these? Do modern TUI developers need to support them? Or can they be ignored like how most modern web developers ignore IE 4 support? That's why I keep asking you which terminals you refer to. Experience from 30 years ago may no longer be relevant. > and much important software doesn’t look at it either. Rich does. https://rich.readthedocs.io/en/latest/_modules/rich/console.html?highlight=COLORTERM# https://rich.readthedocs.io/en/latest/_modules/rich/console....

eesmith 4y ago

Which terminals are you concerned about? I can totally understand that support for (say) a Wyse WY60 may be lacking, and understand how the authors don't consider that to be an issue. It looks like you can style to the terminal capabilities, using https://rich.readthedocs.io/en/latest/reference/style.html https://rich.readthedocs.io/en/latest/reference/style.html .

chrismorgan 4y ago
Just what I said in my original comment: the colours are unreliable. Bold might change the colour or might be almost indistinguishable. Bright white might be higher contrast (on dark terminals) or zero contrast (on some light terminals). Blue might be easy to read (on most newer dark terminals) or very painful to read and almost invisible (on most older dark terminals). Yellow might be brighter than the default colour, or low contrast and not great to read. You just don’t know about any of this stuff unless you check it (which is possible in some terminals, but even then it’s a bit risky as a strategy). The technical aspects of colour support are fairly uninteresting. The inconsistency of the actual colours is the problem.
- eesmith 4y ago
  > the colours are unreliable And as I asked in my followup, in which terminals ? In any case, my point was that once you checked them, it looks like Rich can handle the configuration, and you can set up a theme to use, and textualize will let you pass in a Rich configuration.
  - chrismorgan 4y ago
    > once you checked them You can’t guarantee that you can check them, and that’s the problem. I haven’t directly surveyed terminal support for the relevant OSC sequences (I wish someone would make a thorough terminal feature comparison—in theory terminfo databases would be part of this, but in practice the scheme is thoroughly broken), but from what I’ve heard I would expect a reasonably strong correlation between support for that and support for 24-bit colour. That is, you are unlikely to be able to check the colours on the very environments where you most need to. As far as static checking of terminal capabilities is concerned, I think it’s reasonable to say that everything’s completely broken by design there too. Everything builds upon the idea of a $TERM variable being right and terminfo databases having relevant entries and matching reality, and they’re just not. $TERM will be missing or wrong extremely often, and terminfo databases are regularly out of date, and if you try to use a “correct” value for $TERM you’ll often find various software (especially old software, but even new stuff sometimes) falls over, normally in the direction of claiming that your terminal is incapable of doing something that it is actually capable of. This got to be such a problem that $COLORTERM was introduced, which is more likely to describe the true capabilities of your terminal, but still not quite always even if it’s there, and much important software doesn’t look at it either. If you’re familiar with web history, it’s a similar sort of issue to what happened in the User-Agent header, and for similar reasons. So then, you’re left with maybe some notion of the terminal’s capabilities, and maybe the ability to find out what the colours actually are, but you can’t depend on either of these, and so you can’t in the general case depend on the values of any colours.
    - eesmith 4y ago
      > You can’t guarantee that you can check them, and that’s the problem. Understood. I misread your mention of "checking" as meaning for an organization which wants to deploy a TUI internally, where they can check all of the supported terminals. > That is, you are unlikely to be able to check the colours on the very environments where you most need to. Which terminals are these? Do modern TUI developers need to support them? Or can they be ignored like how most modern web developers ignore IE 4 support? That's why I keep asking you which terminals you refer to. Experience from 30 years ago may no longer be relevant. > and much important software doesn’t look at it either. Rich does. https://rich.readthedocs.io/en/latest/_modules/rich/console.html?highlight=COLORTERM# https://rich.readthedocs.io/en/latest/_modules/rich/console....