SUMMARY Commit 270d6ea3247bb41a51535129e4b1c8eef51cf316 breaks the ability to use intensive colors. This commit claims to fix the readability issue 405345, but the bug reporter indicated in https://www.mail-archive.com/kde-bugs-dist@kde.org/msg343586.html that the bug was fixed by an unrelated commit a year prior. The motivation for removing the intensive color, as far as I can tell, is laid out in https://www.mail-archive.com/kde-bugs-dist@kde.org/msg341954.html However, this email by a non-KDE developer misses that, if you want to not have an intense color, you can simply choose a color scheme that has the same normal and intense color settings. That comment raises as an issue, black-on-white color schemes readability. STEPS TO REPRODUCE 1. Request an intensive font color in the color selection dialog, or use a standard font color scheme with intense colors. 2. Print an intensive font color, i.e., echo -e '\e[1mfoobar OBSERVED RESULT The color of the font is not as requested, it is simply the normal color. EXPECTED RESULT The color of the font should be as specified in the intense color column. SOFTWARE/OS VERSIONS This is present as of 270d6ea3247bb41a51535129e4b1c8eef51cf316 in master, or 82806a2c129f8fa4b21be25b4108eecd8d460625 in 20.12.0, which cherry picks that commit. ADDITIONAL INFORMATION A better solution to the readability issues raised in https://www.mail-archive.com/kde-bugs-dist@kde.org/msg341954.html is to use the existing robust configuration options available to adjust the dark-on-light color schemes to have richer, rather than fainter, intense colors. There is no reason to remove simultaneously remove a configuration option, and change the default behavior that users have expected for over a decade. I propose to revert the commit in question, and adjust the defaults in the dark-on-light color schemes. P.S. The default colors in the faint categories are probably my fault (sorry)---I chose them somewhat randomly back when I implemented faint color support.
I'm not sure if this is completely related, but since the last update the intense colors are no more applied in Konsole though the option "Draw intense colors in bold font" is selected.
Confirmed after upgrading to release service (applications) 20.12. I think it should be applied to konsolepart since other apps such as yakuake suffer from this bug. Please fix ASAP. Thanks!!
My initial description of the bug is not quite correct, so please see https://invent.kde.org/utilities/konsole/-/merge_requests/299 where I've implemented an option to allow for both the old and new behavior. The patch applies on top of 20.12.0---and in fact is what I'm testing with. I'd appreciate anyone willing to test this out and give feedback---please notice that the tests I have run right now are VERY MINIMAL. That said, I am planning on using it on my personal machine.
(In reply to Antonio Russo from comment #3) > I'd appreciate anyone willing to test this out and give feedback---please > notice that the tests I have run right now are VERY MINIMAL. Thanks a lot! My terminal is readable again on "Linux Colors" scheme with your patchset :)
Thanks. Reverting commit 270d6ea3 restores the previous colours for me.
This is fixed as of 2d58ed02. I'm leaving this open, since it's still broken in 20.12.0.
My preferred console font doesn't even support literal bold. I wasn't aware there were people who actually want such a thing. As for the rationale that there is no other "bold alone" code... Shouldn't it work to specify (eg) \e[1m\e[38;2;50;50;50m ? I also notice the intensive behaviour already (before this bug was introduced) ignored RBG colours... So you don't even need to put the colour after the bold code.
FYI: This has been merged into the 20.12 release branch, so it should be fixed in 20.12.1 . There's also a patch (I wrote) that adds a configuration option for the alternative behavior, so it's unlikely we'll see another regression.