| Summary: | Konsole ignores the \e[0;1m reset code | ||
|---|---|---|---|
| Product: | [Applications] konsole | Reporter: | kde |
| Component: | emulation | Assignee: | Konsole Developer <konsole-devel> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | herzenschein, kde.overhead457, ninjalj, tcanabrava, vasyl.demin |
| Priority: | NOR | Keywords: | qt6 |
| Version: | 24.02.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | A picture showing the issue in konsole, and it working as intended in xterm | ||
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. This was done on https://invent.kde.org/utilities/konsole/-/merge_requests/920 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… (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. (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. > 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. (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. |
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