new | ask | show | jobs
johncoltrane 12 hours 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 12 hours 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 11 hours 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 :-).
mort96 11 hours ago  [ - ]

Running a software project means making choices. Currently, the choice is made to make blue text unreadable. That's not a great choice, in my opinion.

hnlmorg 10 hours ago  [ - ]

> the current de-facto standard is set by xterm.

That’s true for 256 colour and various other escape codes too. But I wouldn’t say it’s true for 16 colour pallet.

hnlmorg 10 hours ago  [ - ]

Quite a few terminal emulators do this already. Including the one I maintain.

SAI_Peregrinus 11 hours ago  [ - ]

There are fewer blue cones in the fovea centralis than there are in the surrounding parts of the macula, so humans can't resolve details as well in blue light.

mort96 10 hours ago  [ - ]

Which is why people who understand color tend to add a bit of green in to make a color which still looks deep blue but is much brighter than what #00f looks like