On 17.02.2019 20:24, Jonathan A. Kollasch wrote: > On Fri, Feb 15, 2019 at 04:08:37AM +0000, David Holland wrote: >> On Fri, Feb 15, 2019 at 04:43:24AM +0100, Kamil Rytarowski wrote: >> > I'm for adding colors... >> >> I kind of agree with jnemeth; but as long as it isn't on by default I >> don't care that much. > > Seconded; as long as it's off by default I'm not going to feel this is > something worth my effort to oppose. I already find myself touching > /etc/terminal-colors.d/disable on new GNU/Linux boxes, so I feel > something along those lines to enable it here would be reasonable. > >> Can we, however, please have colors that are not angry fruit salad? My >> understanding is that sufficiently recent xterm and terminfo is >> capable of handling arbitrary rgb colors, so there's therefore no need >> to make everyone's eyes fall out. > > That's more a palette issue... ANSI gives us 8 colors (16 if you think > that "bold" should indicate another color rather than heavier weight > text). It's difficult to get a combination of > black/red/green/yellow/blue/magenta/white to not look like angry fruit > salad, unless you significantly diverge from the generally accepted look > for those color names. If you want to advance to the 256 color with > 6x6x6 color cube, or 24-bit color modes, you may quickly take this > thread into literal 'what color should we paint it' bike shedding. > >> Better still would be a scheme that can adjust to the existing text >> and background color of the terminal, but that's probably still hard. > > While an interesting idea, that sounds like a solution waiting for a > problem to me. > > Jonathan Kollasch > I'm going to get in touch of people active for making console trucolor to help to design LS_COLORS etc. We could skip ansi/legacy phase and switch directly to 24bits and keep a fallback for terminals with ansi palette.
Attachment:
signature.asc
Description: OpenPGP digital signature