Bug 235147

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!