GNOME Bugzilla – Bug 774794
[Feature request] Option to disable bright colors for bold text
Last modified: 2017-12-08 12:58:39 UTC
Created attachment 340446 [details] Bold text displayed with bright colors Some color palettes use 16 colors instead of 8. The most notable example is Solarized, which is included in gnome-terminal. These palettes need to "take over" the 8 bright colors, which is usually achieved by disabling bold text. The option to disable bright colors for bold text is available in macOS' Terminal app, as well as in third-party terminal emulators like iTerm. Sadly, GNOME users do not have access to such an option in gnome-terminal, making the support for the built-in Solarized palette incomplete. I attached two screenshots to demonstrate the issue, with and without bright colors for bold text with the Solarized Dark palette. A good explanation is also available here: https://github.com/seebi/dircolors-solarized#understanding-solarized-colors-in-terminals
Created attachment 340447 [details] Bold text displayed without bright colors
(In reply to Antoine Cotten from comment #0) > A good explanation is > also available here: > https://github.com/seebi/dircolors-solarized#understanding-solarized-colors- > in-terminals It also says: "Many terminal emulators offer an option to disable the use of bright colors for bold, and you must not do so. Often, new users of Solarized will be confused when they change their terminal emulator's color palette to Solarized but haven't yet installed Solarized-specific color themes for all their terminal applications (e.g. mutt, ls's dircolors, irssi, and their colorized shell prompts). They will see texts that are hard to read or disappear entirely. The solution isn't to disable bright colors; the solution is to install Solarized color themes for all terminal applications and then you will have all 16 colors." So, even if we add this option we probably shouldn't disable bright colours for bold by default. What is supposed to happen when 'bright colours for bold' is disabled? Instead of using the bright colour entry from the palette to go with the bold, it should use the non-bright counterpart and show a bold typeface?
Fair point, and I do *not* believe this option should be enabled by default. However the shell itself displays the colors configured in the terminal emulator, therefore built-in commands like 'ls' tend to display gradients of gray when the text is bold. The custom prompt in my screenshot is another relevant example, many trendy Zsh prompts across the web use "powerline" bold chars which colors can not be rendered in gnome-terminal when the Solarized palette is selected. When 'bright colours for bold' is disabled the equivalent non-bright color is printed instead. The user can of course feel free to theme text-based applications accordingly, but by experience the option tends to solve the Solarized-related issues instead of introducing invisible text. That said I'd be glad to see examples that contradict my statement.
Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 762247 ***
(In reply to Debarshi Ray from comment #2) > It also says: > > "Many terminal emulators offer an option to disable the use of bright colors > for bold, and you must not do so. [...] > The solution isn't to disable bright colors; the > solution is to install Solarized color themes for all terminal applications > and then you will have all 16 colors." This statement was made by some random guy implementing some LS_COLORS, not Solarized's author. And in my firm opinion this statement is false. He totally misses the point that with the legacy behavior (bold is also bright), the first 8 colors (that is, half of Solarized's colors) cannot be made bold. [Strictly speaking: they can, using the 256-color escape sequence format. However, it's not available for the for 8 colors via terminfo/libtinfo, which plenty of apps rely on. Also, it's an ugly idea to require to use 256-color escape sequence formats when we're talking about a 16-color color scheme.] If he's happy with the limited choice he wants to force on users, (that is, only 8 colors available in non-bold, and 16 in bold), he can without any problem create an LS_COLORS definition that uses these color+boldness combinations only, even if the user disables bright-for-bold. That is, he's asking the user to choose a particular setting, rather than creating his color definitions in a way that's immune to the user's choice, which he could easily do. That's a totally wrong approach. I'd argue that Solarized is buggy in the sense that the author apparently did not take the bright-for-bold misfeature into account, and did not design the color scheme (assign the colors to the first 8 or the next 8 slots) accordingly, plus misses to give any advice on this topic on the homepage. And the only way to overcome this problem is to offer a possibility to disable this bright-for-bold behavior (and probably even disable it _by default_ for Solarized). See also bug 655030 comments 14-17 for how I believe the overall design should look like. > What is supposed to happen when 'bright colours for bold' is disabled? > Instead of using the bright colour entry from the palette to go with the > bold, it should use the non-bright counterpart and show a bold typeface? It would mean that the SGR 1 (\e[1m) escape sequence, which is currently a nightmare mess of bright-and/or-bold, becomes bold and nothing else, bold only, leaving the color intact. The only sane behavior, alas not what we have currently for crazy legacy reasons.