In FC5 I could enter unicode codepoints, for example a heart sign '♥', by pressing Ctrl and Shift, then the number (Ctrl-Shift-2-6-6-5). In FC6 this changed, without any mention in the release notes, to Ctrl-Shift-u-2-6-6-5. In rawhide it seems to have changed again, and I don't know what it changed to. Please can we stop changing it?
The change has certainly be mentioned in the release notes of the GTK+ version where it was changed. It has not been changed since then, and C-S-u 2665 works fine for me. ♥
mclasen: You're running rawhide? It's definitely broken here. Even dead-key accents are broken. There's a key mapped to ISO_Level3_Shift (usually AltGr, but on this PowerBook keyboard it's some other key). Pressing that key in conjunction with the keys ; ' # [ or ] followed by a letter used to give me accents. Now it doesn't.
dead-keys work in xterm, but not anything using gtk+ xev sees this when I press ISO_Level3_Shift and ; followed by e ... KeyPress event, serial 26, synthetic NO, window 0x4600001, root 0x4d, subw 0x0, time 3130167399, (264,205), root:(289,305), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 29, synthetic NO, window 0x4600001, root 0x4d, subw 0x0, time 3130167919, (264,205), root:(289,305), state 0x80, keycode 47 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 29, synthetic NO, window 0x4600001, root 0x4d, subw 0x0, time 3130167999, (264,205), root:(289,305), state 0x80, keycode 47 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0x4600001, root 0x4d, subw 0x0, time 3130168149, (264,205), root:(289,305), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 29, synthetic NO, window 0x4600001, root 0x4d, subw 0x0, time 3130168218, (264,205), root:(289,305), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: True KeyPress event, serial 29, synthetic NO, window 0x4600001, root 0x4d, subw 0x0, time 3130168218, (264,205), root:(289,305), state 0x0, keycode 0 (keysym 0xe9, eacute), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a9) "é" XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0x4600001, root 0x4d, subw 0x0, time 3130168269, (264,205), root:(289,305), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False In xterm, that gets rendered as "é". In gnome-terminal, I get "´e"
If I run gnome-terminal on a FC6 machine, displaying on the local display (over SSH), dead-keys work fine. If I copy that same gnome-terminal binary and all its libraries as found by 'ldd', and run it as follows, it has the same problem as the FC7 version. s $ ./ld-2.5.so --library-path `pwd` ./gnome-terminal --disable-factory
Fixed by 'unset GTK_IM_MODULE' -- dead keys and Ctrl-Shift-u-X-X-X-X seem to work now¹. It's set to 'xim'. Why did that get enabled and why does it eat my normal keyboard setup? (¹ Well, Ctrl-Shift-u-X-X... actually crashes gnome-terminal, but that's probably a separate bug)
I cannot tell you why GTK_IM_MODULE is set in your environment. It is certainly not set in any /etc/profile.d scriptlets installed by core packages. Either some misguided extras package is doing that, or you just forgot that you set it yourself... I have not been able to reproduce a crash with GTK_IM_MODULE=xim in gnome-terminal. C-S-u seems to be a kill-line keybinding in gnome-terminal... Can you give me the exact key sequence that crashes your terminal, and a stacktrace ?
Furthermore, Unicode input not working with xim is not surprising at all, since Unicode input is a feature of the default GTK+ input method. It is up to the individual input method if they fallback to the default input method or not. I believe scim does chain up to the default input method if it can't use a key.
The crash is without xim -- it's bug #235160 (which you seem to have found already). I've certainly done nothing to set GTK_IM_MODULE myself, and not knowingly installed anything to do with input methods. This started happening when I used yum to update from FC6 to rawhide. /etc/X11/xinit/xinputrc seems to be the culprit. It's an alternatives file -- a symlink to /etc/alternatives/xinputrc which in turn is a symlink to /etc/X11/xinit/xinput.d/scim.conf Removing scim should do the trick. It seems that merely having scim installed didn't have this effect in FC6; it does in F7. (I'll check that shortly). I don't know why I had scim installed -- I can only assume that something had a dependency on it. Certainly there are no dependencies on it now (apart from scim-pinyin) so I've removed them both.
the GTK_IM_MODULE=xim ends up in the environment if you have scim, but not scim-gtk installed. Don't know how that happened to your system.
So, the question is why you ended up without scim-gtk. Maybe we have a missing dependency and a broken upgrade path there ? Moving to scim for further investigation...
scim-gtk was split out of scim-libs for F7 since we have scim-bridge-gtk as the default gtkimm now so no point to install two gtk immodules. Perhaps you yum installed scim-pinyin which pulls in scim-libs and scim but not any immodules (scim-bridge-gtk, scim-qtimm, or scim-gtk), in that case yes now you will end up with GTK_IM_MODULE=xim rather than GTK_IM_MODULE=scim in FC6. Not really sure what can be done about that: the recommended way to install Chinese language support is "yum group install chinese-support".
I've never voluntarily installed any of that, although I have a vague recollection of emacs depending on it.
Ok. I don't know of any dependencies on scim packages outside the scim packages themselves; certainly emacs shouldn't. No clues in the yum logs? :)
See also bug 209626.
The unicode input fallback should be fixed for scim-bridge in f8. Also scim-lang-* metapackages have been added to pull in the right gtkimmodules by default. Perhaps we should keep a bug open for fixing fallback in scim-gtk?
Nevermind, actually bug 209626 is the scim-bridge bug and this is the scim bug.
I tested im-scim and scim-bridge. C-S-u 2665 works fine for me.
> I tested im-scim and scim-bridge. C-S-u 2665 works fine for me. scim-bridge works fine I agree, but with the scim gtkimmodule preedit is still not displayed for me. Maybe this could be pushed upstream though.
fixed in 1.4.7-13-fc9.
Thanks!