Bug 405345

+1

To give a bit more context:

The SGR 1 escape sequence, output by e.g.
  echo -e '\e[1mfoobar'
is defined in ECMA-48 § 8.3.117 as "bold or increased intensity".

The most frequent interpretation by graphical terminal emulators is "both: bold and increased intensity".

With 256-color and later in many terminal emulators true color support emerging, and still no unambiguous "bold" on the rise, this approach no longer really makes sense.

Certain color schemes, most notably Solarized requires that the colors remain unchanged, that is, this escape sequence means "bold" only.

GNOME Terminal 3.28 + VTE 0.52 added a new config option "Show bold text in bright colors", toggling whether this particular escape sequence does "both" (when enabled, the old behavior) or "bold only" (when disabled, the new behavior).

GNOME Terminal 3.32 + VTE 0.56, to be released today, flips its default to "bold only" (disabled state of the checkbox).

See https://bugzilla.gnome.org/show_bug.cgi?id=762247 for the GNOME Terminal discussion, and a few comments about the expected consequences.

(Note that in case of VTE, the color is only ever brightened if it was switched to using the legacy SGR 30 .. 37 escape sequences (combined with SGR 1), and never if it was received using the 256-color capable new escape sequences SGR 38:5:0 .. 38:5:7.)

The Kitty terminal emulator strictly only enables "bold" on this escape sequence, and cannot switch to the bright counterpart. That is, its behavior is the same as GNOME Terminal's brand new default. See https://github.com/kovidgoyal/kitty/issues/197.

Also note that with black background, "bold" and "increased intensity" both work towards making the text more prominently stand out. With white background, however, these two concepts work against each other. Bold stands out more, while increased intensity blends more with the background hence is harder to read. The literal meaning of the word "bold", plus the "faint" attribute which is the opposite of this one, along with the fact that dark background was the dominant when this standard was created, also suggests that "bold" is probably the better one to go with. See more thoughts on this at https://bugzilla.gnome.org/show_bug.cgi?id=791596.

Now that we have 16 million colors, and no standalone "bold" flag, we (at least Kitty and GNOME Terminals – I have no contact with macOS Terminal.app guys) believe that terminal emulation should be pushed to the direction when the current mess is cleaned up, and this ambiguous flag continues to live on with "bold only" meaning. It would be lovely if Konsole joined us, too.

> In konsole, the option is "[ ] Print light as bold" which is the inverse
> and IMHO does not make so much sense.

I fully agree.

Fixed just a few days ago in the upcoming KDE Applications 19.04.0. :)

Awesome! Thank you! :-)

Neither master nor 19.04 has it fixed.

Oh sorry, I thought this was fixed by your fix for https://cgit.kde.org/konsole.git/commit/?id=41693fe9ee263f8f2281852a740ee52d55f003ef, which fixed the issues with bold text for me.

Is there any progress or can I help with fixing this?

The practical impact of this issue is that it makes base16 color schemes unable/harder to use.  

In base16, the "intense" colors are usually some gray tones used for status bars, gutters, or other interface elements.  If you then want to print something in "bold red" it will end up being printed as "bold gray", for example.

A possibly relevant merge request was started @ https://invent.kde.org/utilities/konsole/-/merge_requests/282

Git commit 270d6ea3247bb41a51535129e4b1c8eef51cf316 by Kurt Hindenburg, on behalf of Carlos Alves.
Committed on 01/12/2020 at 03:19.
Pushed by hindenburg into branch 'master'.

Fix bold character color paint

Konsole was painting 'bold' character as 'faint bold' character.
FIXED-IN: 20.12

M  +1    -7    src/Screen.cpp

https://invent.kde.org/utilities/konsole/commit/270d6ea3247bb41a51535129e4b1c8eef51cf316

Git commit 82806a2c129f8fa4b21be25b4108eecd8d460625 by Kurt Hindenburg, on behalf of Carlos Alves.
Committed on 01/12/2020 at 03:25.
Pushed by hindenburg into branch 'release/20.12'.

Fix bold character color paint

Konsole was painting 'bold' character as 'faint bold' character.
FIXED-IN: 20.12
(cherry picked from commit 270d6ea3247bb41a51535129e4b1c8eef51cf316)

M  +1    -7    src/Screen.cpp

https://invent.kde.org/utilities/konsole/commit/82806a2c129f8fa4b21be25b4108eecd8d460625

Is there anyway to keep using old behavior that bold texts are always printed with intense colors? Seems that there's no way to use intense colors for bold texts, and intense colors are no longer used in konsole 20.12.0.

Please provide a way to change this back!
Some of us rely on "bold" changing the color intensity, just like it does in the TTY.

Created attachment 133999 [details]
Git commit template comments no visible

I'm using the nano-syntax-highlighting package in Arch Linux and the git commit template's colors are broken

Created attachment 134000 [details]
The git commit template when I remove the # at the beginning of the line

Axel, can you provide us the correct colors that this is supposed to look?

Created attachment 134002 [details]
git commit template in Konsole 20.08.3

This is the same colors for Konsole 20.08.3.

The following command should print all four combinations of (normal, bold) x (normal, faint):

echo -e '\e[0;31mRed\n\e[1;31mRed (bold)\n\e[1;91mLight red (bold)\n\e[0;91mLight red\e[0m'

Created attachment 134003 [details]
konsole colors

Looks right to me.

Like some others have commented, please add a setting to revert to the old behaviour. Should I make a new issue about this? For now I'll just revert the commit in my local build.

It was never impossible to print bold red:

echo -e '\e[0;38;2;255;0;0mred \e[1mboldred \e[0m normal'

The present patch (270d6ea32) is essentially equivalent to setting all the intensive colors to the same color as the normal ones.  (Note that the 90-97 character codes used here as an example are not standardized---see https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf or https://en.wikipedia.org/wiki/ANSI_escape_code .  We interpret these codes on a best-guess basis.)

Please see https://bugs.kde.org/show_bug.cgi?id=430311 .  I am preparing a patch there that:

- fixes the light color themes (as mentioned here they have reversed intensive semantics);
- uses bold fonts unconditionally for RGB and 256-color spaces (there is no intensive color meaning when a specific color is mentioned as here); and
- again allows for intensive colors to be used.

This avoids breaking decades-old expectations without impeding the development of modern terminal color schemes (use RGB for those).

But this

echo -e '\e[0;38;2;255;0;0mred \e[1mboldred \e[0m normal'

does not print the same red as

echo -e '\e[0;31mRed\n\e[1;31mRed (bold)\e[0m'

and you cannot use RGB colors in all terminals.

If you use a bas16 colorscheme and "bright" colors are various gray tones, then \e1;31m should still print the bold variant of 31 (red) and not a gray.

If you want the two following reds to be the same:

echo -e '\e[0;31mRed\n\e[1;31mRed (bold)\e[0m'

then set those two red colors to be the same in the configuration: right click->Edit current profile->appearance->color scheme & font->edit-> change whichever intense color to be the same as the normal one.

I, as well as the other people here who were startled this morning with un-configureable and different behavior, do not want my intense text to have the same color as my non-intense text.  It is (was) just a simple configuration option! :)

> If you use a bas16 colorscheme and "bright" colors are various gray tones, then \e1;31m should still print the bold variant of 31 (red) and not a gray.

I'm not sure I understand this comment.  31 will be whatever color you define it to be in Konsole---which will by default be some red variant.  Did echo -e '\e1;31m text' ever come out gray for you?

Stefan, what application is using an "intense or bold" font to describe gutters, and expects the colors to be entirely different ("grey tones" entirely unrelated to the normal color)?  I have never seen anything like that, and I cannot help but think we should not be breaking many other applications that use the ANSI specification more to the letter.

I think the actual bug you want is to be able to set the 90-97 colors differently than the intensive colors---is that correct? You mentioned these ANSI codes earlier?

The idea of base16 (https://github.com/chriskempson/base16) is to carefully design the first 16 ansi colors so that they can be used by various tools for interface coloring and highlighting, e.g. by vim or bat and delta.  The benefit of this is that you can emulate "true colors" in termainsl that don't suport that and that many tools can easily share the same color scheme by just referencing the first 16 ansi colors.

Most terminals I know (Konsole, gnome-terminal, xfce4-terminal, Apple Terminal, iTerm2) support accessing the intense colors via the 90s range and googling "ansi colors" indicates that this is so common that you can rely on this feature in practicse.

Base16 relies on that and uses the 30s range for coloring and the 90s range for gray tones for the interface.

Some terminals print 1;31 as "bright bold red" by default, some print 1;31 as "bold red".  Most of them (excluding Konsole) have an option like "Intensify bold colors"  which toggles between both modes.  I think that this might also be a good solution to fix this issue in Konsole. :)

I attached two example screenshots from xfce4-terminal.

Created attachment 134041 [details]
xfce4-terminal 1;31 is the same color as 0;31, but bold.

Created attachment 134042 [details]
xfce4-terminal 1;31 is the same color as 1;91.

I've got a partial patch that adds back such an option.  It needs more testing, but it is tentatively working:

https://invent.kde.org/utilities/konsole/-/merge_requests/299

The commit in question has been reverted, but my MR, https://invent.kde.org/utilities/konsole/-/merge_requests/299 , should implement this feature request.

I'd appreciate feedback and testing from interested parties.

I’d like to try it but I haven’t done any KDE dev yet and have not found an easy guide on how to compile Konsole.  Could you please point me to some docs?

Hello Stefan!  konsole is actually very easy to build, as long as you have all the dependencies (and there's the rub).  If you're on a Debian testing, you *can* easily get them with

sudo apt-get build-dep konsole

(I'm sure there are similar mechanisms on other distributions, I just don't know them).
However: older releases may not have sufficiently up-to-date dependencies.  You can move forward here, you'll just run into errors later on.  You definitely need cmake 3.13, QT 5.12, and KF5 frameworks 5.68 (or later).

# Get the source

git clone https://invent.kde.org/aerusso/konsole.git -b pulls/revert-no-intense-color
cd konsole

At this point, I will tell you to do whatever due diligence you feel is appropriate to validate that what you've downloaded is safe.

# Next, configure the source:

cmake .

If you run into errors here, you will need to read them and figure out what else needs to be installed.  

# Compile the code!

Here, -j8 tells make to use 8 threads, making it compile ~8x faster (if you have that many cores).

make -j8

# Run it:

./bin/konsole

# Bugs that are not related to my change:

There's a new toolbar that I cannot figure out how to disable.  It also might not go away when you go back to your old version of konsole (!!!).  To get rid of it, find any konsoleui.rc files (probably in ~/.local/share/konsole/konsoleui.rc or ~/.local/share/kxmlgui5/konsole/konsoleui.rc), and delete them.

# What to find:

Edit current profile -> Appearance -> Color scheme & font -> Use bright color for intense text

Un-select that, and apply the change.

Antonio, your patch fixes my problems too:

- yellows started looking orange for example
- mc (midnight commander) doesn't show directories as white but greyish
- mcedit doesn't show tabs and trailing spaces and the cursor disapears

With you patch applied everything goes back to normal for me, so thanks!

Created attachment 134315 [details]
ANSI colors in konsole 20.12.0

This is right now (frameworks 5.77.0, plasma-desktop 5.20.4, konsole 20.12.0, qt5-5.15.2)

Created attachment 134316 [details]
ANSI colors in konsole from pulls/revert-no-intense-color branch

This one is with Antonio's branch

Antonio,

I finally had the time to compile Konsole from your branch.
Initially I did not find the new option - I expected it to be at the same place as the existing "Draw intense text in bold font" option.

Making it part of the color scheme itself has some benefits though, since theme authors can activate the option for base16 themes directly in the "*.colorscheme" files (or can't they?).

Anyhow, once activated, it works as expected. Thank you! :)

I believe this issue can be closed, the bug seems to have been resolved for all the parties' satisfaction.

I'm not closing it in case some use case got left behind :)

The MR I opened [1] has not been merged---it's still marked as draft, and there are serious design issues with it as it currently stands (it increases technical debt in an part of the code base that needs to be very fast).

I have not had a chance to redo the patchset.  I'd also like to understand the performance impact for this patch (and more generally, for many of the new features being added).  I also cannot say that this is a high priority for me to work on.

Please don't close this bug unless you have confirmed that someone else's patch has been merged, or you are making an executive decision that Konsole will not support the feature requested here.

[1] https://invent.kde.org/utilities/konsole/-/merge_requests/299

Was the original change reverted then?

Because the last few versions have been working fine for me and I didn't notice your marge request was still open.

But if there's more use cases to contemplate, that your patch addresses then yes, let's keep this issue open.

(BTW, I'm not an official KDE developer and I'm in no position to make an executive decision about this or other issues, sorry if it seemd that way).

What’s the status of this issue?  I’ve been using a self-compiled patched version konsole during the last year while I was waiting for this feature to be released. :)

However, konsole  21.08.0 still doesn't have the new *Use bright colors for intense text* option.