[kwin] [Bug 469834] cannot change both width and height of client geometry (maybe a race?)
https://bugs.kde.org/show_bug.cgi?id=469834 Antonio Russo changed: What|Removed |Added Resolution|INTENTIONAL |--- Ever confirmed|0 |1 Status|RESOLVED|REOPENED --- Comment #3 from Antonio Russo --- Yes, I suspected that the async operations were doing this, but I was never able to figure out how to overcome that. In particular, I don't know how to instantiate a QRect object (is it spelled "rect"?)? Could you please give me the exact script that you are saying will allow me to change both the width and height at the same time? If such a script indeed exists, I definitely agree this bug should be closed. Thank you, Antonio -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 469834] cannot change both width and height of client geometry (maybe a race?)
https://bugs.kde.org/show_bug.cgi?id=469834 --- Comment #1 from Antonio Russo --- I forgot to mention: this is a wayland regression. It is broken on kwin_wayland, but works on kwin_X11. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 469834] New: cannot change both width and height of client geometry (maybe a race?)
https://bugs.kde.org/show_bug.cgi?id=469834 Bug ID: 469834 Summary: cannot change both width and height of client geometry (maybe a race?) Classification: Plasma Product: kwin Version: 5.25.2 Platform: Debian testing OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: scripting Assignee: kwin-bugs-n...@kde.org Reporter: aeru...@aerusso.net Target Milestone: --- STEPS TO REPRODUCE 1. startplasma-interactiveconsole --kwin 2. Run this script: ``` const clients = workspace.clientList(); var client = clients[clients.length-1]; client.geometry.height = 1000; client.geometry.width = 1000; ``` (Obviously, make sure that the scripting console is the most recently opened window, otherwise you'll be resizing some other window on your desktop). OBSERVED RESULT Only the width is changed. (invert the order to get the height to be changed) EXPECTED RESULT Both the height and width are changed. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian testing KDE Plasma Version: 4:5.27.2-1 KDE Frameworks Version: 5.103.0-1 Qt Version: 5.15.8-2 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 466782] main window placed directly over old window when all toolbars and menubars are disabled
https://bugs.kde.org/show_bug.cgi?id=466782 --- Comment #1 from Antonio Russo --- As a workaround, you can set, in the [General] section of ~/.config/konsolerc , AllowKDEAppsToRememberWindowPositions=false -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 466782] New: main window placed directly over old window when all toolbars and menubars are disabled
https://bugs.kde.org/show_bug.cgi?id=466782 Bug ID: 466782 Summary: main window placed directly over old window when all toolbars and menubars are disabled Classification: Applications Product: konsole Version: 22.12.3 Platform: Debian unstable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: aeru...@aerusso.net Target Milestone: --- SUMMARY The main window of konsole is placed in an unfortunate way when called from, e.g., a global keyboard shortcut to open a terminal that calls the executable `/usr/bin/konsole`. The window is often paced in the same spot on every command invocation. STEPS TO REPRODUCE 1. Remove ~/.config/konsole* 2. Run /usr/bin/konsole 3. Disable both the main and session toolbar. 4. Disable the menu bar. 5. Close the konsole session. 6. Run /usr/bin/konsole 7. Run /usr/bin/konsole again OBSERVED RESULT The second new konsole window appears directly above the first. EXPECTED RESULT The second new konsole window should be placed per the kwin rules, either centered or "least overlap", etc. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian unstable (available in About System) KDE Plasma Version: 4:5.27.2-1 (plasma-workspace) KDE Frameworks Version: 5.103.0-1 Qt Version: 5.15.8+dfsg-3 ADDITIONAL INFORMATION I have not tried to dig into options or the code very much. That said, having this work differently when the menu bar is enabled vs disabled seems like unwanted behavior. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 405345] Impossible to print "bold red". Bold is always printed as intense/light color
https://bugs.kde.org/show_bug.cgi?id=405345 --- Comment #36 from Antonio Russo --- 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 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 430311] Intensive color selection broken as of 270d6ea3
https://bugs.kde.org/show_bug.cgi?id=430311 --- Comment #8 from Antonio Russo --- 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. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 405345] Impossible to print "bold red". Bold is always printed as intense/light color
https://bugs.kde.org/show_bug.cgi?id=405345 --- Comment #30 from Antonio Russo --- 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. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 430311] Intensive color selection broken as of 270d6ea3
https://bugs.kde.org/show_bug.cgi?id=430311 --- Comment #6 from Antonio Russo --- This is fixed as of 2d58ed02. I'm leaving this open, since it's still broken in 20.12.0. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 405345] Impossible to print "bold red". Bold is always printed as intense/light color
https://bugs.kde.org/show_bug.cgi?id=405345 Antonio Russo changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #28 from Antonio Russo --- 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. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 430311] Intensive color selection broken as of 270d6ea3
https://bugs.kde.org/show_bug.cgi?id=430311 --- Comment #3 from Antonio Russo --- 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. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 405345] Impossible to print "bold red". Bold is always printed as intense/light color
https://bugs.kde.org/show_bug.cgi?id=405345 --- Comment #27 from Antonio Russo --- 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 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 405345] Impossible to print "bold red". Bold is always printed as intense/light color
https://bugs.kde.org/show_bug.cgi?id=405345
--- Comment #23 from Antonio Russo ---
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?
--
You are receiving this mail because:
You are watching all bug changes.
[konsole] [Bug 405345] Impossible to print "bold red". Bold is always printed as intense/light color
https://bugs.kde.org/show_bug.cgi?id=405345 --- Comment #22 from Antonio Russo --- 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? -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 405345] Impossible to print "bold red". Bold is always printed as intense/light color
https://bugs.kde.org/show_bug.cgi?id=405345 Antonio Russo changed: What|Removed |Added CC||aeru...@aerusso.net --- Comment #20 from Antonio Russo --- 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). -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 430311] New: Intensive color selection broken as of 270d6ea3
https://bugs.kde.org/show_bug.cgi?id=430311 Bug ID: 430311 Summary: Intensive color selection broken as of 270d6ea3 Product: konsole Version: 20.12.0 Platform: unspecified OS: All Status: REPORTED Severity: normal Priority: NOR Component: font Assignee: konsole-de...@kde.org Reporter: aeru...@aerusso.net Target Milestone: --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 393911] kwinrulesrc rewritten unnecessarily
https://bugs.kde.org/show_bug.cgi?id=393911 --- Comment #5 from Antonio Russo <antonio.e.ru...@gmail.com> --- Thanks! After patching, I'm not seeing the unnecessary updates anymore. (The original symptom was *terrible* lag when opening new Konsole windows during a ZFS scrub) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 393911] New: kwinrulesrc rewritten unnecessarily
https://bugs.kde.org/show_bug.cgi?id=393911 Bug ID: 393911 Summary: kwinrulesrc rewritten unnecessarily Product: kwin Version: 5.12.4 Platform: Debian unstable OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: rules Assignee: kwin-bugs-n...@kde.org Reporter: antonio.e.ru...@gmail.com Target Milestone: --- ~/.config/kwinrulesrc appears to be modified (stat shows changed times) every time a window is created or destroyed that matches a rule in that file. This is (obviously) not great for SSD lifetimes, power consumption, etc., but---making things worse---kwin happens to *block* on this write, so the whole desktop freezes. This is particularly painful on devices that are a slow. [This seems to be distinct from #347111.] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 389330] Plasma popup notifications sometimes get pushed "behind the desktop"
https://bugs.kde.org/show_bug.cgi?id=389330 Antonio Russo <antonio.e.ru...@gmail.com> changed: What|Removed |Added Severity|minor |wishlist -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 389330] Plasma popup notifications sometimes get pushed "behind the desktop"
https://bugs.kde.org/show_bug.cgi?id=389330 Antonio Russo <antonio.e.ru...@gmail.com> changed: What|Removed |Added Severity|normal |minor -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 389330] Plasma popup notifications sometimes get pushed "behind the desktop"
https://bugs.kde.org/show_bug.cgi?id=389330 --- Comment #1 from Antonio Russo <antonio.e.ru...@gmail.com> --- Sorry, to reproduce this, you need, in .config/kwinrc: [Compositing] HiddenPreviews=4 Also, you might need to somewhat rapidly swap around opening the status and notifications window and changing to other desktops. I'm not even sure why I had that setting in kwinrc to begin with, so I'm going to lower this priority a lot. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 389330] New: Plasma popup notifications sometimes get pushed "behind the desktop"
https://bugs.kde.org/show_bug.cgi?id=389330 Bug ID: 389330 Summary: Plasma popup notifications sometimes get pushed "behind the desktop" Product: plasmashell Version: 5.10.5 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: antonio.e.ru...@gmail.com Target Milestone: 1.0 Steps to reproduce: 0. Have a panel with an attached notification window (e.g., the system tray, "Status and Notifications"). 1. Switch to desktop 1. 2. Activate that panel-window (e.g., the status and notification section). It should be visible as expected. 3. Change desktop using kwin's "Switch to Desktop 2" keybinding (default is Ctrl-F2). The panel-window should disappear. 4. Change back to desktop 1. Try opening any panel-window again. It won't be visible (this is the bug). If you use the "toggle present windows (current desktop)" (default Ctrl-F9), you'll see a blank window, which represents the panel-window that isn't visible. Clicking on it raises it, and brings plasmashell back into a reasonable state. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 384863] Global menu not exported for different user
https://bugs.kde.org/show_bug.cgi?id=384863 --- Comment #2 from Antonio Russo <antonio.e.ru...@gmail.com> --- Yeah, I saw that a user dbus cannot be accessed by another (unprivileged) user. I was hoping there might already some work on this. Maybe something like https://www.freedesktop.org/wiki/Software/DBusRemote/ but maybe something like "(user) dbus over (system) dbus" would be relatively easy to implement? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 384863] New: Global menu not exported for different user
https://bugs.kde.org/show_bug.cgi?id=384863 Bug ID: 384863 Summary: Global menu not exported for different user Product: plasmashell Version: 5.10.5 Platform: Debian unstable OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Global Menu Assignee: k...@privat.broulik.de Reporter: antonio.e.ru...@gmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 If a user "mainuser" starts a KDE session, and then starts some application "someapplication" running as another user "otheruser", as it stands, someapplication will not have its global menu available in mainuser's KDE session (though it otherwise integrates fine into that X session: clipboard, etc). It would be nice if the global menu worked for programs running as another user. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 384861] New: Auto-hide panel should raise when global menu is triggered via Alt-key
https://bugs.kde.org/show_bug.cgi?id=384861 Bug ID: 384861 Summary: Auto-hide panel should raise when global menu is triggered via Alt-key Product: plasmashell Version: 5.10.5 Platform: Debian unstable OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Global Menu Assignee: k...@privat.broulik.de Reporter: antonio.e.ru...@gmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 As described in https://bugs.kde.org/show_bug.cgi?id=376726 , the global menu is now properly triggered when a key (say alt-F for the File menu). However, if the panel containing the global menu is set to "auto-hide", the panel itself may not be visible. IMO, the panel should un-hide when its contained global menu is activated, the same way that activating the application menu (launcher or K menu) raises the containing panel. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 362171] Patch review requested for implementation SGR 2/8/9/53 (dim/conceal/strikeout/overline)
https://bugs.kde.org/show_bug.cgi?id=362171 --- Comment #12 from Antonio Russo <antonio.e.ru...@gmail.com> --- I really appreciate your getting back to me. Thank you. I cannot "publish" the patch without it having a "review"---and I don't think I am allowed to review it myself (?). The first step in the patch creation process required uploading a diff---which for subsequent patches is rejected because the parent revision is not yet known to reviewboard (or, it was not properly detected). I think. Hindenburg glanced at this bug a couple months ago. Could you possibly contact him, or should I maybe ping him directly? -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 362171] Patch review requested for implementation SGR 2/8/9/53 (dim/conceal/strikeout/overline)
https://bugs.kde.org/show_bug.cgi?id=362171 --- Comment #10 from Antonio Russo <antonio.e.ru...@gmail.com> --- I am glad that the patch works for others. Sorry if this is turning into spam. I made a review request https://git.reviewboard.kde.org/r/128390/ but since I have a series of patches that depend on the previous one, I was not sure how to upload the sequence without squashing all the commits. What should I now do? Wait for someone to review my draft proposal? Thanks, Antonio -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 362171] Patch review requested for implementation SGR 2/8/9/53 (dim/conceal/strikeout/overline)
https://bugs.kde.org/show_bug.cgi?id=362171 --- Comment #7 from Antonio Russo <antonio.e.ru...@gmail.com> --- The revised patchset has support for all default color schemes. There should be no issues using these color schemes. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 362171] Patch review requested for implementation SGR 2/8/9/53 (dim/conceal/strikeout/overline)
https://bugs.kde.org/show_bug.cgi?id=362171 --- Comment #6 from Antonio Russo <antonio.e.ru...@gmail.com> --- Created attachment 99927 --> https://bugs.kde.org/attachment.cgi?id=99927=edit Revised complete patchset tar.gz of 6 patches -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 362171] Patch review requested for implementation SGR 2/8/9/53 (dim/conceal/strikeout/overline)
https://bugs.kde.org/show_bug.cgi?id=362171 --- Comment #5 from Antonio Russo <antonio.e.ru...@gmail.com> --- The patch depends on a color style to implement the "faint" intensities for each color. I did this specifically for Linux.colorscheme (and it should is included in the patch) but did not get around to the other themes. My eye is not particularly suited for aesthetic choices, and the choice of faint colors for the themes is such a choice (in particular the solarized and light themes seemed to require some thought). Assuming this bug gets enough attention to be included, but not enough for other people with better aesthetics than me to work on the themes, I'll hack up some faint colors. I'll point out that the patch also includes in a fully functional (but completely untested) gui for setting the faint color theme---right next to setting the other colors and intense colors. Notwithstanding that, the overline and strikeout font effects should function correctly. Are you seeing those with the patch applied? If not, could you confirm that your terminal font supports overline and strikeout effects? -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 362171] Patch review requested for implementation SGR 2/8/9/53 (dim/conceal/strikeout/overline)
https://bugs.kde.org/show_bug.cgi?id=362171 --- Comment #3 from Antonio Russo <antonio.e.ru...@gmail.com> --- The attachment should be a tar.gz with 7 patches. On my debian machine it extracts with tar -xf . I've been using a version of konsole with these patches applied for about a month now, and haven't hit any bugs. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 362171] Patch review requested for implementation SGR 2/8/9/53 (dim/conceal/strikeout/overline)
https://bugs.kde.org/show_bug.cgi?id=362171 --- Comment #1 from Antonio Russo <antonio.e.ru...@gmail.com> --- Created attachment 98546 --> https://bugs.kde.org/attachment.cgi?id=98546=edit SGR Implementation -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 362171] New: Patch review requested for implementation SGR 2/8/9/53 (dim/conceal/strikeout/overline)
https://bugs.kde.org/show_bug.cgi?id=362171 Bug ID: 362171 Summary: Patch review requested for implementation SGR 2/8/9/53 (dim/conceal/strikeout/overline) Product: konsole Version: master Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: emulation Assignee: konsole-de...@kde.org Reporter: antonio.e.ru...@gmail.com Escape codes SGR 2, SGR 8, SGR 9, and SGR 53 are not implemented in Konsole. All except SGR 53 are implemented in xterm. Reproducible: Always Steps to Reproduce: echo -e 'D\e[2mD\e[9mD\e[53mD\e[8mD' Actual Results: 5 D symbols, all identical Expected Results: 4 D symbols, the last three with "dim," "faint" or "half" intensity, the last two with "strikeout" font, and the last one overlined. The final, fifth D should not be visible. I posted an earlier, less-complete patch set to the development mailing list. I don't know if that was the correct venue---or if this one is either. -- You are receiving this mail because: You are watching all bug changes.
