Bug 482985 - Konsole ignores the \e[0;1m reset code
Summary: Konsole ignores the \e[0;1m reset code
Status: CONFIRMED
Alias: None
Product: konsole
Classification: Applications
Component: emulation (show other bugs)
Version: 24.02.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords: qt6
Depends on:
Blocks:
 
Reported: 2024-03-09 14:41 UTC by kde
Modified: 2024-03-23 14:57 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
A picture showing the issue in konsole, and it working as intended in xterm (21.14 KB, image/png)
2024-03-09 14:41 UTC, kde
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kde 2024-03-09 14:41:39 UTC
Created attachment 166794 [details]
A picture showing the issue in konsole, and it working as intended in xterm

SUMMARY
After updating to KDE 6, Konsole ignores the reset part of \e[0;1m (this possibly applies to other \e[0;something as well?)

STEPS TO REPRODUCE
1. Type the following command: printf '\e[1;34mfoo\e[0;1mbar\n'
2. Observe the result 

OBSERVED RESULT
Blue and bold text "foobar"

EXPECTED RESULT
Blue and bold text "foo" followed by white and bold "bar"

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 6.7.9-zen1-1-zen (64-bit)
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Graphics Platform: X11

ADDITIONAL INFORMATION
If I try to replicate this in Xterm, everything works as expected. 
PS: \e[0 works as expected
Comment 1 kde 2024-03-10 18:24:36 UTC
It appears this is caused by the update to KDE 6 changing the breeze color scheme's intense foreground color to light blue. (https://imgur.com/a/6KUTaCM) This isn't how it was in KDE 5 and its current state, it produces horrible results with programs such as Paru. (https://imgur.com/a/GEgGI8V)
I suspect this was not intentional and it should be considered to revert the defaults to what they were in KDE 5.
Comment 2 ninjalj 2024-03-11 22:40:19 UTC
This was done on https://invent.kde.org/utilities/konsole/-/merge_requests/920
Comment 3 Thomas Lübking 2024-03-13 08:38:11 UTC
export LESS_TERMCAP_mb=$'\e[1;34m'     # begin bold
export LESS_TERMCAP_md=$'\e[1;34m'     # begin blink
export LESS_TERMCAP_so=$'\e[01;44;37m' # begin reverse video
export LESS_TERMCAP_us=$'\e[01m'       # begin underline
export LESS_TERMCAP_me=$'\e[0m'        # reset bold/blink
export LESS_TERMCAP_se=$'\e[0m'        # reset reverse video
export LESS_TERMCAP_ue=$'\e[0m'        # reset underline
export GROFF_NO_SGR=1                  # for konsole and gnome-terminal, no idea whether that's still required

Obviously first check whether the environment is set and then don't override that.

Doing this by manipulating the palette will trigger false positives and occasionally lead to blue-on-blue invisible text.

Nothing has changed in the last decade w/ the VDG…
Comment 4 tcanabrava 2024-03-13 09:03:17 UTC
(In reply to Thomas Lübking from comment #3)
> export LESS_TERMCAP_mb=$'\e[1;34m'     # begin bold
> export LESS_TERMCAP_md=$'\e[1;34m'     # begin blink
> export LESS_TERMCAP_so=$'\e[01;44;37m' # begin reverse video
> export LESS_TERMCAP_us=$'\e[01m'       # begin underline
> export LESS_TERMCAP_me=$'\e[0m'        # reset bold/blink
> export LESS_TERMCAP_se=$'\e[0m'        # reset reverse video
> export LESS_TERMCAP_ue=$'\e[0m'        # reset underline
> export GROFF_NO_SGR=1                  # for konsole and gnome-terminal, no
> idea whether that's still required
> 
> Obviously first check whether the environment is set and then don't override
> that.
> 
> Doing this by manipulating the palette will trigger false positives and
> occasionally lead to blue-on-blue invisible text.
> 
> Nothing has changed in the last decade w/ the VDG…

Friendly reminder that each time a snarky remark is done, morale decreases and good people that would help solve bugs, will disappear.
Comment 5 kde 2024-03-13 15:10:02 UTC
(In reply to ninjalj from comment #2)
> This was done on
> https://invent.kde.org/utilities/konsole/-/merge_requests/920

Thanks for pointing it out. Is it possible to discuss to revert this? I strongly believe that this has caused more troubles than it solved.
Comment 6 Thiago Sueto 2024-03-23 14:08:02 UTC
> it produces horrible results with programs such as Paru. (https://imgur.com/a/GEgGI8V)

That was intentional. Whether you personally disliked the color or not, you can see how the paru output now actually makes each step clear and the most important information easy to find now.

Pretty sure before it was all white with pretty much no distinction at all, maybe at most bold IIRC.

> First check whether the environment is set and then don't override that.

This sounds like a possible fix if I understand correctly, yes.

> Is it possible to discuss to revert this?

I'd much rather fix the actual issue, the fact that the palette overrides custom colors set manually by the user / ignores the reset code.

Reverting this would be just a temporary paliative that doesn't fix the issue. Especially given we already provide custom palettes and let users set the intense color themselves.

As a workaround you can do yourself, you can set Foreground Intense Color back to white (255,255,255), which was the original default anyway.
Comment 7 kde 2024-03-23 14:57:25 UTC
(In reply to Thiago Sueto from comment #6)
> > it produces horrible results with programs such as Paru. (https://imgur.com/a/GEgGI8V)
> 
> That was intentional. Whether you personally disliked the color or not, you
> can see how the paru output now actually makes each step clear and the most
> important information easy to find now.
> 
> Pretty sure before it was all white with pretty much no distinction at all,
> maybe at most bold IIRC.
> 
> > First check whether the environment is set and then don't override that.
> 
> This sounds like a possible fix if I understand correctly, yes.
> 
> > Is it possible to discuss to revert this?
> 
> I'd much rather fix the actual issue, the fact that the palette overrides
> custom colors set manually by the user / ignores the reset code.
> 
> Reverting this would be just a temporary paliative that doesn't fix the
> issue. Especially given we already provide custom palettes and let users set
> the intense color themselves.
> 
> As a workaround you can do yourself, you can set Foreground Intense Color
> back to white (255,255,255), which was the original default anyway.

I've already performed the workaround.
I still believe that the way it used to be before is way cleaner (https://imgur.com/a/Q29jziG vs https://imgur.com/a/GEgGI8V). But that is not up to me to decide.