6 ms·

I know 16 colours is limiting, but one of my biggest pet peeves is CLI / TUI developers creating their own custom themes using colours outside of that because o

by hnlmorg 8mo ago

I know 16 colours is limiting, but one of my biggest pet peeves is CLI / TUI developers creating their own custom themes using colours outside of that because odds are, they’re going to generate a colour scheme that is harder to read for a lot of people with visual impairments, people who prefer a white or coloured background for eye comfort, people are dyslexic and find non-black backgrounds easier to read, and others with visual difficulties, reading difficulties, or those who just like a different colour scheme per project or environment they’re working in so they can multitask more easily. And the developers answer to this loss of control is to create multiple colour schemes and allow the user to configure the app. Which then means their users have to set up their terminal defaults and then configure every fscking app that ignores those terminal defaults(!!!) instead of defining their required colour schemes once in the terminal. People use the terminal not because it’s pretty but because they find a text interface more efficient. If you want to make pretty things then build a web frontend. But please do not break my terminal because you feel the need to impose on me your own favourite colours of the hour.

ffaser5gxlsll 8mo ago
> but one of my biggest pet peeves is CLI / TUI developers creating their own custom themes An even bigger one is hardcoding black and white instead of using foreground/background and use reverse when needed.
mort96 8mo ago
I agree. I always customize the blue color on my terminal because dark blue on black is completely unreadable to me (and I'm not even color blind!). For some reason, every single terminal emulator defaults to a blue that's unreadable on a black background (I think typically #00f). If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.
- kevin_thibedeau 8mo ago
  Most of them are emulating the EGA/VGA palette which was a regression from the CGA terminal colors. https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-palette/ https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...
  - tracker1 8mo ago
    Not really, because the dark yellow (not brown) is used... it's similar, but not the same in most terminals... brown as dark yellow for cga was a kind of short to a different color mix than the natural position which most terminals now use... actual screen effectiveness/brightness is different as well. Kind of anal about this since I started with a lot of CGA and EGA displays when I was in my late teens and early 20s and relatively involved in the ANSi art scene. Here's a related project I'm working on for playing doors in a web browser. https://github.com/bbs-land/webterm-dos-ansi https://github.com/bbs-land/webterm-dos-ansi
    - Aardwolf 8mo ago
      I have no idea if this was the reason behind turning the dark yellow into brown, but the brown was a much better looking color for DOS games so it was a good call They could also have done something about the two magentas though... E.g. made one of them orange?
      - tracker1 8mo ago
        The light red usually appeared somewhat orangy/peachy, it's generally used as flesh for ansi artworks. ex: https://16colo.rs/pack/ice-200207a/ti-war.ice https://16colo.rs/pack/ice-200207a/ti-war.ice
      - tracker1 8mo ago
        I think it was just determined that brown would be more useful than the darker yellow in practice. Other xterm colors are also a bit off from CGA/EGA/VGA DOS colors.
- jve 8mo ago
  Is there a human that can read that dark blue on black or is it just us who has their eyes wired differently? I have to select that text to change the background to read it.
  - johncoltrane 8mo ago
    No one can and people have been complaining about it for decades. But there is no standard or standard body anywhere for terminal colors so there is no obvious way to improve this situation. And no urgency either, because all terminal emulators allow users to customize the palette anyway.
    - mort96 8mo ago
      If I was the maintainer of a terminal emulator, I would see a quite obvious way to improve the situation for my users: change the default colors so that dark blue is brighter. There's no obvious way to unilaterally improve the situation across the whole ecosystem, that's true. But I don't understand why individual terminal emulator maintainers don't fix it for their users.
      - johncoltrane 8mo ago
        Because it means making choices, breaking assumptions, etc.. They have made it user-customizable so they don't have to go through all that. FWIW, the current de-facto standard is set by xterm. Here is a relevant excerpt of its source code: ! Disclaimer: there are no standard colors used in terminal emulation. ! ! The choice for color4 and color12 is a tradeoff between contrast, depending ! on whether they are used for text or backgrounds. Note that either color4 or ! color12 would be used for text, while only color4 would be used for a ! background. These are treated specially, since the luminosity of blue is ! only about half that of red/green, and is typically not accounted for in the ! RGB scheme. ! ! Blue text on a black background should be readable. ! Blue backgrounds should not be "too" bright. ! ! Originally color4/color12 were set to the names blue3/blue !*VT100*color4: blue3 !*VT100*color12: blue ! ! They are from rgb.txt respectively: ! 0 0 205 blue3 ! 0 0 255 blue ! However, blue3 is not readable on a black background. ! ! Another choice was from the Debian settings: !*VT100*color4: DodgerBlue1 !*VT100*color12: SteelBlue1 ! ! From rgb.txt: ! 30 144 255 DodgerBlue1 ! 99 184 255 SteelBlue1 ! ! Some users object to this choice because the background (color4) is brighter ! than they are accustomed. Others point out that the different weights for ! the red/green components make it appear to be not really blue. Finally, it ! provides poor contrast against color13 and color14. ! ! The current choice uses equal weights for red/green (effectively adding a ! gray to the result). It is brighter than the original choice, and provides ! more contrast between color12 and color13, color14 than SteelBlue1 did. ! Contrast of color4 against black is slightly improved over the original. ! ! Some refinement is certainly possible (you are welcome to try) -TD Make that what you will :-).
- ErroneousBosh 8mo ago
  Not just me then? My "dark blue" is always a kind of pale washed-out-bluey-grey because of that.
- hinkley 8mo ago
  And I filed a PR because an author used yellow and hadn’t assigned orange to any purpose, which is actually legible on a white terminal where yellow never is.
AshamedCaptain 8mo ago
Sadly, if users start customizing the 256 color palette, developers will simply switch to true color to continue this mess further...
heliumtera 8mo ago
yes, this. the reason i use wolf (firefox fork) is because i can easily disallow styles overriding, font overriding, and use bitmap fonts. nothing else. now that react devs finished destroying the web they have to impose their superior taste into terminal through 800mbs TUIs.
Aardwolf 8mo ago
gdb (the debugger) sometimes prints dark blue text on a black background, which is unreadable. I customize the dark blue color when possible in VTE's due to this, but it's not always possible everywhere But I wonder what the developers of gdb were using that made them not notice this
zzo38computer 8mo ago
If I make a terminal emulator, I would probably not support true colours in text but only in pictures (and it would be possible to disable pictures). I probably would not implement 256-colours either, because I agree with you; the user configures their own colours to use, and the terminal should use them. For text, only sixteen colours can be used. Similarly, the user can also set their own fonts for the terminal, just as you can with colours and other functions. (However, some programs will have a reason to configure the fonts and palettes for the specific use, although most won't and even if they do the user might disable those features.) A program can have an option (possibly by environment variable) to disable colours entirely; this might be necessary even if you can disable colours in the terminal emulator, because a program might want to use such things as reverse video, underlined text, etc to indicate some things when colours are disabled. (Disabled colours can also be useful if you do not have a colour display or if you want to print out a screenshot without a colour printer.)

by hnlmorg 8mo ago

ffaser5gxlsll 8mo ago

> but one of my biggest pet peeves is CLI / TUI developers creating their own custom themes An even bigger one is hardcoding black and white instead of using foreground/background and use reverse when needed.

mort96 8mo ago

I agree. I always customize the blue color on my terminal because dark blue on black is completely unreadable to me (and I'm not even color blind!). For some reason, every single terminal emulator defaults to a blue that's unreadable on a black background (I think typically #00f). If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.

kevin_thibedeau 8mo ago
Most of them are emulating the EGA/VGA palette which was a regression from the CGA terminal colors. https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-palette/ https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...
- tracker1 8mo ago
  Not really, because the dark yellow (not brown) is used... it's similar, but not the same in most terminals... brown as dark yellow for cga was a kind of short to a different color mix than the natural position which most terminals now use... actual screen effectiveness/brightness is different as well. Kind of anal about this since I started with a lot of CGA and EGA displays when I was in my late teens and early 20s and relatively involved in the ANSi art scene. Here's a related project I'm working on for playing doors in a web browser. https://github.com/bbs-land/webterm-dos-ansi https://github.com/bbs-land/webterm-dos-ansi
  - Aardwolf 8mo ago
    I have no idea if this was the reason behind turning the dark yellow into brown, but the brown was a much better looking color for DOS games so it was a good call They could also have done something about the two magentas though... E.g. made one of them orange?
    - tracker1 8mo ago
      The light red usually appeared somewhat orangy/peachy, it's generally used as flesh for ansi artworks. ex: https://16colo.rs/pack/ice-200207a/ti-war.ice https://16colo.rs/pack/ice-200207a/ti-war.ice
    - tracker1 8mo ago
      I think it was just determined that brown would be more useful than the darker yellow in practice. Other xterm colors are also a bit off from CGA/EGA/VGA DOS colors.
jve 8mo ago
Is there a human that can read that dark blue on black or is it just us who has their eyes wired differently? I have to select that text to change the background to read it.
- johncoltrane 8mo ago
  No one can and people have been complaining about it for decades. But there is no standard or standard body anywhere for terminal colors so there is no obvious way to improve this situation. And no urgency either, because all terminal emulators allow users to customize the palette anyway.
  - mort96 8mo ago
    If I was the maintainer of a terminal emulator, I would see a quite obvious way to improve the situation for my users: change the default colors so that dark blue is brighter. There's no obvious way to unilaterally improve the situation across the whole ecosystem, that's true. But I don't understand why individual terminal emulator maintainers don't fix it for their users.
    - johncoltrane 8mo ago
      Because it means making choices, breaking assumptions, etc.. They have made it user-customizable so they don't have to go through all that. FWIW, the current de-facto standard is set by xterm. Here is a relevant excerpt of its source code: ! Disclaimer: there are no standard colors used in terminal emulation. ! ! The choice for color4 and color12 is a tradeoff between contrast, depending ! on whether they are used for text or backgrounds. Note that either color4 or ! color12 would be used for text, while only color4 would be used for a ! background. These are treated specially, since the luminosity of blue is ! only about half that of red/green, and is typically not accounted for in the ! RGB scheme. ! ! Blue text on a black background should be readable. ! Blue backgrounds should not be "too" bright. ! ! Originally color4/color12 were set to the names blue3/blue !*VT100*color4: blue3 !*VT100*color12: blue ! ! They are from rgb.txt respectively: ! 0 0 205 blue3 ! 0 0 255 blue ! However, blue3 is not readable on a black background. ! ! Another choice was from the Debian settings: !*VT100*color4: DodgerBlue1 !*VT100*color12: SteelBlue1 ! ! From rgb.txt: ! 30 144 255 DodgerBlue1 ! 99 184 255 SteelBlue1 ! ! Some users object to this choice because the background (color4) is brighter ! than they are accustomed. Others point out that the different weights for ! the red/green components make it appear to be not really blue. Finally, it ! provides poor contrast against color13 and color14. ! ! The current choice uses equal weights for red/green (effectively adding a ! gray to the result). It is brighter than the original choice, and provides ! more contrast between color12 and color13, color14 than SteelBlue1 did. ! Contrast of color4 against black is slightly improved over the original. ! ! Some refinement is certainly possible (you are welcome to try) -TD Make that what you will :-).
ErroneousBosh 8mo ago
Not just me then? My "dark blue" is always a kind of pale washed-out-bluey-grey because of that.
hinkley 8mo ago
And I filed a PR because an author used yellow and hadn’t assigned orange to any purpose, which is actually legible on a white terminal where yellow never is.

AshamedCaptain 8mo ago

Sadly, if users start customizing the 256 color palette, developers will simply switch to true color to continue this mess further...

heliumtera 8mo ago

yes, this. the reason i use wolf (firefox fork) is because i can easily disallow styles overriding, font overriding, and use bitmap fonts. nothing else. now that react devs finished destroying the web they have to impose their superior taste into terminal through 800mbs TUIs.

Aardwolf 8mo ago

gdb (the debugger) sometimes prints dark blue text on a black background, which is unreadable. I customize the dark blue color when possible in VTE's due to this, but it's not always possible everywhere But I wonder what the developers of gdb were using that made them not notice this

zzo38computer 8mo ago

If I make a terminal emulator, I would probably not support true colours in text but only in pictures (and it would be possible to disable pictures). I probably would not implement 256-colours either, because I agree with you; the user configures their own colours to use, and the terminal should use them. For text, only sixteen colours can be used. Similarly, the user can also set their own fonts for the terminal, just as you can with colours and other functions. (However, some programs will have a reason to configure the fonts and palettes for the specific use, although most won't and even if they do the user might disable those features.) A program can have an option (possibly by environment variable) to disable colours entirely; this might be necessary even if you can disable colours in the terminal emulator, because a program might want to use such things as reverse video, underlined text, etc to indicate some things when colours are disabled. (Disabled colours can also be useful if you do not have a colour display or if you want to print out a screenshot without a colour printer.)