Change default draw_bold_text_with_bright_colors behavior #2779
Comments
|
My initial reaction is that this is a good idea. If I forget all the history, I'm having trouble coming up with a rational for why bold and bright would be tied together at all. I'll be curious to see what examples @egmontkob digs up for negative feedback, but it's got to all be historical support. I'd hope applications would be able to adapt, generally. Though, we'd just be changing the default value of FWIW, I googled "ANSI Bold" and the first link I got was this one: http://www.lihaoyi.com/post/BuildyourownCommandLinewithANSIescapecodes.html, which makes it seem like "Bold" and "Bright" are the same thing, so it's pretty clear this is a confused topic in the wild. I've had (most) of my bright colors set to the same color as the non-bright version, which I'm thinking was probably a result of me not knowing about this bright/bold option. Now I'm wondering if I can come up with a nice set of actual bright colors for my theme (One Dark). I'll change my setting and see how things go, just as another point of reference. |
|
I also think, that it's a good idea, since a lot of people could be unfamiliar with this bold/bright story. The folks who are aware of such thing can always find this setting in a config in my opinion. |
|
Here are some related links I could dig up. (I might edit the comment to extend the list later.) They are roughly in decreasing order of relevance. The last couple ones are about adding this setting, or pre-requisite cleanups that we did in gnome-terminal; not about flipping the default. Basically: there's not much buzz going on about it. No big outcry, no big praises either. (As I said in #2776 (comment), I expected worse.) https://bugzilla.gnome.org/show_bug.cgi?id=762247#c29 comments 29-33 https://bugs.launchpad.net/terminator/+bug/1820544 https://bugzilla.redhat.com/show_bug.cgi?id=1687141 kovidgoyal/kitty#197 https://askubuntu.com/q/1156880 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910078 |
|
Thanks a bunch for digging all this up for us @egmontkob.
Hopefully as more terminals push in this direction, applications will adjust as well. And again, for those that do not we have an option, though it's not possible to enable |
The option has some "historical" background, for example it could break ncurses applications like alsamixer, however the default to `true` seems strange nowadays, because it makes impossible to draw bold text in a "normal" color. Some other terminals (e.g. vte, kitty) also started default to `false` here. We're not removing the option, but just flipping a bit, and knowing that users tend to copy paste our config in a past, will likely continue to have it defaulted to `true` in their configuration files. The only problem is the users who don't have this option in a config file now or new users, however the change in color is noticable and it also stated very clear in our configuration file, so it shouldn't be a problem to flip things back. Implements alacritty#2779
The option has some "historical" background, for example it could break ncurses applications like alsamixer, however the default to `true` seems strange nowadays, because it makes impossible to draw bold text in a "normal" color. Some other terminals (e.g. vte, kitty) also started default to `false` here. We're not removing the option, but just flipping a bit, and knowing that users tend to copy paste our config in a past, will likely continue to have it defaulted to `true` in their configuration files. The only problem is the users who don't have this option in a config file now or new users, however the change in color is noticeable and it also stated very clear in our configuration file, so it shouldn't be a problem to flip things back. Implements alacritty#2779
The option has some "historical" background, for example it could break ncurses applications like alsamixer, however the default to `true` seems strange nowadays, because it makes impossible to draw bold text in a "normal" color. Some other terminals (e.g. vte, kitty) also started default to `false` here. We're not removing the option, but just flipping a bit, and knowing that users tend to copy paste our config in a past, will likely continue to have it defaulted to `true` in their configuration files. The only problem is the users who don't have this option in a config file now or new users, however the change in color is noticeable and it also stated very clear in our configuration file, so it shouldn't be a problem to flip things back. Implements alacritty#2779
Since the assumption is usually that bold text is drawn in bright colors, this might break some applications. However some other terminals have already taken this leap, which should lessen the impact for Alacritty. Since this might still be desired and necessary for certain applications, the config option is just switched to draw with normal colors by default, however the old behavior can still be restored. Fixes alacritty#2779.
At the moment, Alacritty draws bold text with the bright colors by default. This can be extremely annoying when the goal is to just get some bold text with non-bright colors and it's not necessary to use this if you actually do want to use bright colors. To make each escape do one thing and do that well, the option
draw_bold_text_with_bright_colorsis currently available to change this behavior.Generally, I think it makes more sense to have this option disabled by default, however a choice was made against that for compatibility with other terminal emulators and keeping up with user expectations.
Kitty has never had any way to get this mixed bold escape and it has come to my knowledge in #2776 that gnome has recently disconnected the bold and bright escapes by default too. With other terminal emulators changing this and offering the chance to make right what has been done wrong in the past, I think it would be a good choice to follow suit here.
However, we're talking about a default option here, so what really matters is how most people feel about this, so I'd like to take this opportunity to get some comments on this possible change. Maybe @kchibisov and @nixpulvis can chime in, however I'm really curious about all kinds of opinions (both for and against this).
The text was updated successfully, but these errors were encountered: