My keyboard features a plethora of dead-keys, and a Compose key. In most apps, including Kate, I can use them hassle-free — for example, Compose + " + u outputs ü, and so does my dead-key for the umlaut (I customized my keyboard layout.) However, Konsole fails to recognize them and inserts � when I am done entering the sequence. >>> import unicodedata >>> good = u"üü" # inserted in Kate (using both methods) and copy-pasted >>> bad = u"��" # inserted directly in Konsole >>> unicodedata.name(good[0]) 'LATIN SMALL LETTER U WITH DIAERESIS' >>> unicodedata.name(bad[0]) 'REPLACEMENT CHARACTER' However, I can insert Unicode characters (even the most complicated ones and even ones outside of BMP) that are on my keyboard (plain AltGr): Alt + o = ó (pl keyboard layout) Compose + ' + o = � Reproducible: Always Steps to Reproduce: 1. Add a Compose key or a dead key to your keyboard layout. (for compose, there is a nice option in advanced keyboard system settings) 2. Try to use it with Konsole. 3. Fail miserably. Actual Results: 'REPLACEMENT CHARACTER' Expected Results: 'LATIN SMALL LETTER U WITH DIAERESIS' Happens with all dead keys and all characters gained via the Compose key. The encoding is set to UTF-8. I can type Unicode characters that are directly available from my keyboard.
I can confirm I get the same bug with Konsole 3.0.1 shipped with Kubuntu 15.04. The temporary solution is to copy/paste the unicode symbols from another application, as indeed: (i) the X Compose key works correctly in other applications (including xterm), (ii) Konsole correctly shows the unicode symbols by copying/pasting.
With konsole "Version 15.08.0" pressing the Compose key gives two inverse question marks; an xterm in the same X11 session works. "dead_Greek" seems to be simply ignored.
I couldn't reproduce this with a current git master snapshot. Reopen if you can still reproduce this issue with a current konsole version.
Hi, I am experiencing the same bug, my dead_greek key is being ignored by konsole. Reproducible: Always Steps to reproduce: 1. xmodmap -e 'keycode 94 = dead_greek' note that keycode 94 is the < > | key on German keyboards, located between Shift_L and Y. For testing purposes, you may want to use 49, which is ` ~ on us-intl, next to the 1 key 2. in konsole, press your dead_greek key, then press j Expected behaviour: a Theta symbol (θ) appears Actual behaviour: the letter 'j' appears It seems like Konsole is still ignoring the key. I am using an up-to-date Konsole Version 17.12.3, as it's in the Arch Linux Repository. Additional Info: The File-Selection dialog for Konsole (When doing File -> Save Output As) exhibits the same behaviour I'm not using the KDE Desktop, but i3 as a WM. With xfce4-terminal and chromium, the dead_greek key works. With konsole, the Compose key does work (compose m u gives me the greek mu symbol, but dead_greek m does not).
(In reply to flo from comment #4) > 1. xmodmap -e 'keycode 94 = dead_greek' > 2. in konsole, press your dead_greek key, then press j Works correctly for me (produces θ) in konsole 17.12.3, under Unity 7 desktop environment on Ubuntu Bionic beta. So it probably depends on some lower level setting or software component, maybe ibus???
I don't have ibus installed on any of my systems; also, I just checked with the `xev` tool: upon pressing <dead_greek> <j>, it produces the attached log. Most importantly, it features: ... KeyPress event, serial 33, synthetic NO, window 0x2e00001, root 0x4e8, subw 0x0, time 22618620, (214,139), root:(218,867), state 0x0, keycode 44 (keysym 0x6a, j), same_screen YES, XLookupString gives 1 bytes: (6a) "j" XmbLookupString gives 1 bytes: (6a) "j" XFilterEvent returns: True KeyPress event, serial 33, synthetic NO, window 0x2e00001, root 0x4e8, subw 0x0, time 22618620, (214,139), root:(218,867), state 0x0, keycode 0 (keysym 0x10003b8, U03B8), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (ce b8) "θ" XFilterEvent returns: False ... Which suggests to me that any X11 application should "just work". What could cause this issue here, shouldn't it work fine without ibus installed, too?
Created attachment 111543 [details] xev excerpt from pressing <dead_greek> <j>
This report was initially about the Compose key; one thing I found (by accident) is that the 'convert-meta' readline variable (check the bash manual page and /etc/inputrc), affects the Compose key; if it's "on" the Compose key doesn't work, if it's "off" the Compose key works as expected. AFAICT, this is a bash configuration issue. The dead_greek issue is a separate issue, let's keep it tracked in a separate bug report; please open a new report, and if you're using bash attach the output of 'bind -V'.
Thanks for the report Chris, are you able to confirm that the character is placed in the document correctly with a recent version of Konsole?
I’m afraid I don’t have a box to test this. This bug was reported 5 years ago, and other people had it last in 2018. If you cannot reproduce this with a recent version yourself (enable a Compose key in Keyboard settings <https://userbase.kde.org/Tutorials/ComposeKey>, and make sure you’re on Xorg), it might have been fixed already.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Chris, I have posted the dead_greek comment in 2018 and I can confirm that by now, this is not an issue any more. Also my compose key works (and has always worked).
I had a chance to test this, and was unable to reproduce it either. I’ll close this bug.