Multi_key / compose does not work when XMODIFIERS="@im=SCIM"

Description of problem:

When a "Compose Key" is configured (using xmodmap or System > Preferences > Hardware > Keyboard > Layouts > Layout options > Compose key position) all X applications use it. However, Emacs doesn't. When the compose key is pressed, Emacs complains: "<Multi-key> is undefined".

Version-Release number of selected component (if applicable):

emacs-22.2-5.fc9.i386.rpm (from F10 release)
emacs-22.3-1.fc10.i386 (from F10 updates-testing)

How reproducible:

Always.

Steps to Reproduce:

1. Start a Gnome session
2. Configure Right Control as Compose Key using System > Preferences > Hardware > Keyboard > Layouts > Layout options > Compose key position
3. From a command line, start "emacs -q"
4. Open a new, empty buffer.
5. Press the right control key, followed by keys [e] and ['].

Actual results:

Emacs will complain: "<Multi-key> is undefined". The characters "e" and "'" will appear in the buffer.

Expected results:

No complaints, and the character "é" (e with acute accent) in the buffer.

Additional info:

This bug makes it impossible to enter texts that are beyond ASCII. Therefore this bug is actually a show stopper.

Some additional information (that I hope could be useful).

I have a Fedora 8 system running Emacs 21.4.1 and a Fedora 10 system with Emacs 22.x (see previous message).

On the F10 system, Emacs 22 complains about the multi_key.
When run on the F10 system with display to the F8 system, it behaves normally (multi_key compose works).

On the F8 system, Emacs 21 behaves normally.
When run on the F8 system with display to the F10 system, it behaves normally.

Java application jEdit shows similar behaviour.

F10 has java version "1.6.0_0"
IcedTea6 1.4 (fedora-7.b12.fc10-i386) Runtime Environment (build 1.6.0_0-b12)
OpenJDK Server VM (build 10.0-b19, mixed mode)

F8 has java version "1.6.0_04"
Java(TM) SE Runtime Environment (build 1.6.0_04-b12)
Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)

Both systems are running jEdit-4.3pre15.

On the F10 system, jEdit ignores the multi_key.
When run on the F10 system with display to the F8 system, it behaves normally (multi_key compose works).

On the F8 system, jEdit behaves normally.
When run on the F8 system with display to the F10 system, it behaves normally.

because both jEdit and Emacs share the same bug and when you use F8 version of xorg, the problem disappears, can there be perhaps something wrong with X configuration on F10? reassigning to xorg (feel free to reassign back to me, if there's nothing wrong on X side)

I can reproduce the problem when booted from the F10 Live CD. I'm not saying that this eliminates the possibility that the problem is related to X settings, but it does eliminate *my* particular X settings.

Steps:
- boot from Live CD
- login
- open terminal window
- $ su -
- # yum install emacs
- # ^D
- $ emacs

Try e.g., right-control. Nothing happens.

System -> Preferences > Hardware > Keyboard > Layouts
Layout Options > Compose Key Position
Select Right Control as Compose
Close

Back to Emacs. Press right-control. Emacs complains "<multi_key> is not defined".

Other applications (e.g. the terminal window) treat control-right now as a compose key.

(In reply to comment #3)

> but it does eliminate *my* particular X settings.
that's exactly what I thought: because two distinct applications (jEdit and emacs) present the same buggy behavior, there might be something rotten in the default X config in F10 - I reassigned the bug to xorg component, so they can see if there's something wrong

Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Just to be sure I understand, because it is important, could you confirm that other applications (e.g., gedit) work correctly wtih the Compose key?

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

(In reply to comment #5)

I've attached X server config file (/etc/X11/xorg.conf) and
X server log file (/var/log/Xorg.*.log). This is from a VirtualBox running a clean install of Fedora 10, with all current updates applied. The problem occurs on other hardware as well.

Have you tried to reproduce the problem with the Live CD, as I described earlier?
This is the easiest and most comfortable way to collect all information you may need.

> Just to be sure I understand, because it is important, could you confirm that
> other applications (e.g., gedit) work correctly wtih the Compose key?

Yes, other apps work correctly with the Compose key.

Created attachment 329863
xorg. conf

Created attachment 329864
Xorg.0.log

As per https://bugzilla.novell.com/show_bug.cgi?id=461243#c14

If you start emacs with "env -u XMODIFIERS emacs", you will find that compose key now works (it does for me). This has been bugging me as well for a long time. Note, this is just a workaround, but might be enough to keep you going until the real fix is found.

See also https://bugzilla.redhat.com/show_bug.cgi?id=493172

Created attachment 339606
sample program

Well, I can confirm this on rawhide but works for me on F-10. I suppose it's because an application somehow fails to create an input-context with XCreateIC and emacs itself doesn't have a keybinding defined for Multi_Key.

Here is a simple program to see and steps to reproduce:
1. install scim and scim-anthy say.
2. build sample program
3. run it with LANG=ja_JP.UTF-8 and XMODIFIERS=@im=SCIM
4. run it with LANG=en_US.UTF-8 and XMODIFIERS=@im=SCIM

Actual Result:
3. works properly and can see the scim panel with ctrl+space and characters appears with the root-window style.
4. fail to create an input-context.

forgot to mention this. when it happens on emacs, XIM doesn't work either due to a fail of XCreateIC.

Throwing in hopefully better direction and putting Peter on CC list.

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

I still see these symptoms with emacs-24.3-11.fc19.i686 and environment variable XMODIFIERS set to the now-default "@im=ibus".

maybe better mention your locale for information I guess.

These are my locale settings.

LC_PAPER=nl_NL
LANG=en_US.utf-8
LC_TIME=en_GB

The problem is also there when I set LANG=C, so I doubt it has a relation to the locale.

(Actually, I must confess that I forgot this issue since I somehow managed to set XMODFIERS=@im=none globally.)

(In reply to Johan Vromans from comment #18)
> These are my locale settings.
>
> LC_PAPER=nl_NL
> LANG=en_US.utf-8
> LC_TIME=en_GB
>
> The problem is also there when I set LANG=C, so I doubt it has a relation to
> the locale.

It does as I mentioned at comment#11

I'm using LANG=en_GB.utf8.

I tried setting LANG=ja_JP.utf8 and found that the problem went away.

Additionaly, I tried LANG=en_GB.iso88591. The problem went away, but I was unable to enter characters outside of the Latin-1 range.

There's some discussion of what sounds like the same issue on the Emacs mailing list: http://thread.gmane.org/gmane.emacs.devel/170835

Meanwhile, I find I am unable to reproduce this issue on Fedora 20.

This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.