5 ms·

is you suggestion that if they had of used 3/4 bit ANSI colors (basic but not high intensity) that you could have remapped "white" to be something that shows up

is you suggestion that if they had of used 3/4 bit ANSI colors (basic but not high intensity) that you could have remapped "white" to be something that shows up in your white terminal? That.... works i guess but it's pretty limiting and only helps people who happened to have completely reworked the definitions of basic things like "white" and "black" and "blue" which would result in a completely unpredictable result for the app creator. A much BETTER solution would be for them to set the background color because they've got a UI specifically designed for dark background.

laumars 8y ago
My solution would be to use the standard 8 colour ANSI escapes. Using the faint and intense shades for when they need to emphasis stuff. If they cannot get the desired effect from that then I'd rather than disabled colour by default and had an optional flag / environmental variable to enable true colour. > That.... works i guess but it's pretty limiting and only helps people who happened to have completely reworked the definitions of basic things like "white" and "black" and "blue" which would result in a completely unpredictable result for the app creator. I completely disagree for a few reasons: 1/ if you're running a white (or any other coloured) terminal then odds are you've already changed the other colours to suite (since other applications use the 3/4bit standard as well). 2/ or if they are just using a preset theme then that theme would have a suitable colour palette already 3/ CLI programs shouldn't be so dependant on the palette of the colours that alternative shades render the tool "unpredictable". It's a CLI tool, not a fancy graphical package. You cannot make any assumptions about the terminal eg what if the user has colour disabled entirely - does that then also make the tool "unpredictable"? What about different terminal typefaces? Or widths? You cannot make any assumptions aside that text will be rendered (and even that isn't a guarantee if you're using unicode). The one exception to this is ASCII / terminal art. But they are justified in using true colour escape sequences since their entire point is pseudo-graphical. > A much BETTER solution would be for them to set the background color because they've got a UI specifically designed for dark background. That's another solution but I fundamentally disagree it is a better one. eg what if people are dyslexic or partially sighted so have their terminal configured for readability reasons? What the developer is doing is overriding that accessibility setting. Unlike many CLI junkies I actually don't mind a bit of colour in the terminal. But I'd honestly rather have developers not using colour at all if they're really that concerned about their output looking identical on every terminal.
- JdeBP 8y ago
  You are imposing limits on the to-do list authors who want a different colour for each field, and have more than 7 fields. (-: * https://screenshots.debian.net/package/yagtd https://screenshots.debian.net/package/yagtd
  - laumars 8y ago
    Again, there are more than 7 colours available if you include the intense and faint palettes. Which is, in my opinion at least, better than the to-do list authors imposing limits on what shell colour schemes I can use. Or alternatively, they can just not use any colours at all. Frankly I don't even have different colour schemes on my JIRA kanban board so the argument that CLI todo lists require true colour support is tenuous at best.
    - JdeBP 8y ago
      There aren't really intense and faint palettes. The conventional indexed colour mapping has 16 "standard" colours in entries 0 to 15, but those aren't really anything to do with either bold or faint attributes. They are not even standard. ITU T.416 does not specify them. There are only eight standard colours in ECMA-48, set by SGR 30 to 37 and 40 to 47. Some emulators substitute a colour modifier for boldface. But not all of them even do that, with several terminal emulators rendering boldface as actual boldface, meaning that that is not a route to a colour change in the first place. As for faint, my terminal emulator is one of the very few that even takes any notice at all of the faint attribute. SGR 90 to 97 and 100 to 107 are not standardized by ECMA-48. They are an extension from aixterm.
      - laumars 8y ago
        Bold and intense are two completely different things in terms of SGR codes, so let's just strike bold from the conversation now. The intence and faint codes are the same SGR ranges as the standard 8 colours but have their additional property encoded in their escape sequence (separated by a semi-colon, as is common with terminal escape sequences). Arguements about whether it is standard or not aside (because there are dozens of standards and no terminal emulator follows any of those standards strictly anyway - instead picking and choosing parts from different standards based on whatever gets the best results the easiest), most terminals do support it. In fact faint and intense are more widely supported than the 8 bit and 24 bit SGR sequences. However if you're really going to get hung up on compatibility and standards then the only safe route is not to use colour at all.

laumars 8y ago

My solution would be to use the standard 8 colour ANSI escapes. Using the faint and intense shades for when they need to emphasis stuff. If they cannot get the desired effect from that then I'd rather than disabled colour by default and had an optional flag / environmental variable to enable true colour. > That.... works i guess but it's pretty limiting and only helps people who happened to have completely reworked the definitions of basic things like "white" and "black" and "blue" which would result in a completely unpredictable result for the app creator. I completely disagree for a few reasons: 1/ if you're running a white (or any other coloured) terminal then odds are you've already changed the other colours to suite (since other applications use the 3/4bit standard as well). 2/ or if they are just using a preset theme then that theme would have a suitable colour palette already 3/ CLI programs shouldn't be so dependant on the palette of the colours that alternative shades render the tool "unpredictable". It's a CLI tool, not a fancy graphical package. You cannot make any assumptions about the terminal eg what if the user has colour disabled entirely - does that then also make the tool "unpredictable"? What about different terminal typefaces? Or widths? You cannot make any assumptions aside that text will be rendered (and even that isn't a guarantee if you're using unicode). The one exception to this is ASCII / terminal art. But they are justified in using true colour escape sequences since their entire point is pseudo-graphical. > A much BETTER solution would be for them to set the background color because they've got a UI specifically designed for dark background. That's another solution but I fundamentally disagree it is a better one. eg what if people are dyslexic or partially sighted so have their terminal configured for readability reasons? What the developer is doing is overriding that accessibility setting. Unlike many CLI junkies I actually don't mind a bit of colour in the terminal. But I'd honestly rather have developers not using colour at all if they're really that concerned about their output looking identical on every terminal.

JdeBP 8y ago
You are imposing limits on the to-do list authors who want a different colour for each field, and have more than 7 fields. (-: * https://screenshots.debian.net/package/yagtd https://screenshots.debian.net/package/yagtd
- laumars 8y ago
  Again, there are more than 7 colours available if you include the intense and faint palettes. Which is, in my opinion at least, better than the to-do list authors imposing limits on what shell colour schemes I can use. Or alternatively, they can just not use any colours at all. Frankly I don't even have different colour schemes on my JIRA kanban board so the argument that CLI todo lists require true colour support is tenuous at best.
  - JdeBP 8y ago
    There aren't really intense and faint palettes. The conventional indexed colour mapping has 16 "standard" colours in entries 0 to 15, but those aren't really anything to do with either bold or faint attributes. They are not even standard. ITU T.416 does not specify them. There are only eight standard colours in ECMA-48, set by SGR 30 to 37 and 40 to 47. Some emulators substitute a colour modifier for boldface. But not all of them even do that, with several terminal emulators rendering boldface as actual boldface, meaning that that is not a route to a colour change in the first place. As for faint, my terminal emulator is one of the very few that even takes any notice at all of the faint attribute. SGR 90 to 97 and 100 to 107 are not standardized by ECMA-48. They are an extension from aixterm.
    - laumars 8y ago
      Bold and intense are two completely different things in terms of SGR codes, so let's just strike bold from the conversation now. The intence and faint codes are the same SGR ranges as the standard 8 colours but have their additional property encoded in their escape sequence (separated by a semi-colon, as is common with terminal escape sequences). Arguements about whether it is standard or not aside (because there are dozens of standards and no terminal emulator follows any of those standards strictly anyway - instead picking and choosing parts from different standards based on whatever gets the best results the easiest), most terminals do support it. In fact faint and intense are more widely supported than the 8 bit and 24 bit SGR sequences. However if you're really going to get hung up on compatibility and standards then the only safe route is not to use colour at all.