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

Bug #493766 reported by David Monniaux on 2009-12-07
140
This bug affects 27 people
Affects Status Importance Assigned to Milestone
emacs23 (Fedora)
Won't Fix
Medium
emacs23 (Ubuntu)
Undecided
Unassigned
emacs24 (Debian)
Fix Released
Unknown
emacs24 (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: emacs23

Ubuntu 9.10
emacs23:
  Installed: 23.1+1-4ubuntu3.1

Using X with a configuration for SCIM input methods, environment variable XMODIFIERS then contains @im=SCIM

Start emacs

Hit Multi_key (aka Compose key, often bound to one of the Windows keys depending on keyboard layout and layout options) ' (single quote) e

You should be getting é (e acute accent)

Instead, emacs complains that <Multi_key> is undefined.

Problem disappears if launching Emacs with XMODIFIERS="'

ProblemType: Bug
Architecture: i386
Date: Mon Dec 7 21:56:37 2009
DistroRelease: Ubuntu 9.10
Package: emacs (not installed)
ProcEnviron:
 LANGUAGE=en_US.UTF-8
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-16.52-generic
SourcePackage: emacs22
Uname: Linux 2.6.31-16-generic i686
XsessionErrors:
 (gnome-settings-daemon:2488): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:2488): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (polkit-gnome-authentication-agent-1:2548): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:2537): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (gnome-panel:2536): Gdk-WARNING **: /build/buildd/gtk+2.0-2.18.3/gdk/x11/gdkdrawable-x11.c:952 drawable is not a pixmap or window

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.

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.

lanig (alainbe) wrote :

In Lucid RC, the same bug arises with XMODIFIERS set at @im=ibus.

This is a very ennoying bug for me it prevents me from editing xelatex french/ japanese files in emacs.

lanig (alainbe) wrote :

Is there any action planned for this bug ? Emacs should not work in the way it does now.

David Monniaux (david-monniaux) wrote :

Problem also for 10.04 lucid.

lanig (alainbe) wrote :

Problem still here in 10.10.
Pleaaaaaaaaaaaase fix it is very annoying and had been here for too long now !

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in emacs23 (Ubuntu):
status: New → Confirmed

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

Apteryx (maxco) wrote :

Emacs 24 using Ubuntu 13.10 is still affected

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.

Ulf Mehlig (umehlig) wrote :

A workaround for me was to "unset" XMODIFIERS via

sudo im-config

choosing "none". Not sure about side-effects, though.

Damien Cassou (cassou) wrote :

I confirm emacs24 and emacs-snapshot are affected in Ubuntu 13.10.

Please add info to
https://bugs.launchpad.net/emacs-snapshot/+bug/1251176
and
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15891

Thank you for the workarounds.

On Ubuntu 13.10, since last reboot, Emacs started not accepting my compose key.
Emacs complains in the mini-buffer that ``<Multi_key> is undefined''. It has always worked up to now.
It works fine in the terminal.

Damien Cassou (cassou) wrote :

Christopher: any success with the workarounds?

vjrj (vjrj) wrote :

Following the workaround for emacs24, I edited:
  sudo vi /usr/share/applications/emacs24.desktop
and changed the line:
  Exec=/usr/bin/emacs24 %F
by:
  Exec=bash -c "unset XMODIFIERS;/usr/bin/emacs24 %F"

Fixed in Emacs trunk revisions 116858 and 116859.

(Well, at least for ibus >= 1.5.)

Changed in emacs23 (Ubuntu):
assignee: nobody → rosa maria (rprosamaria383)
dobey (dobey) on 2014-03-28
Changed in emacs23 (Ubuntu):
assignee: rosa maria (rprosamaria383) → nobody

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.

Jesse Glick (jesse-glick) wrote :

Confirmed workaround from comment #12 in emacs24 24.3+1-2ubuntu1 (Ubuntu 14.04), normally using @im=ibus and the right Ctrl key as the compose key.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in emacs24 (Ubuntu):
status: New → Confirmed

same with Ubuntu 14.04

GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.10.7)
 of 2014-03-07 on toyol, modified by Debian

unsetting XMODIFIERS still is a workaround.

Anders Kaseorg (andersk) wrote :

This was reported upstream (apparently it also affects UIM and IBus):
  http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00867.html
resulting in four upstream patches:
  http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/116856.1.1
  http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/116856.1.2
  http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/116856.1.3
  http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/116856.1.4
also known as 10b7c08..b38653c in emacs.git.

I just tested that adding these four patches fixes the problem on Ubuntu utopic. If anyone else wants to test, here are my packages:

https://launchpad.net/~anders-kaseorg/+archive/ppa/+sourcepub/4270902/+listing-archive-extra

Changed in emacs24 (Debian):
status: Unknown → Confirmed
Michael Kreuzer (penulci) wrote :

The workaround from #12 worked fine for me using Emacs24 on 14.04 (Trusty) for the application launcher.
Adding
alias emacs="XMODIFIERS=@im=none emacs"
alias emacs24="XMODIFIERS=@im=none emacs24"
to .bash_aliases was the workaround I used before to start emacs from console since I could not figure out proper entry for .local/share/applications/emacs24.desktop yet.
Now the application launcher also works fine.

Thanks a lot,
Michael

Changed in emacs24 (Debian):
status: Confirmed → Fix Released
Robie Basak (racb) wrote :

17:14 <rbasak> If someone wants to sponsor emacs24 in bug 493766 it looks fine
               to me but I've just noticed it's in main so I can't upload it.
17:14 <rbasak> (though a merge would be better)

Sorry! One minor note: Origin: backport would be more appropriate for 0017-Further-improve-create_frame_xic-patch.patch as it looks slightly different to what was committed upstream. But I see that it is what went into Debian too.

Anders Kaseorg (andersk) wrote :

The different appearance of 0017-Further-improve-create_frame_xic-patch.patch is due to the slightly different diff algorithms used by Git and Bazaar (http://bramcohen.livejournal.com/37690.html); the actual code change is identical.

If you want to sponsor a merge instead, the one already generated at https://merges.ubuntu.com/e/emacs24/ has been working for me.

Iain Lane (laney) wrote :

Thanks, I'll upload the diff. Please prepare the merge if you're so inclined.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package emacs24 - 24.3+1-4ubuntu2

---------------
emacs24 (24.3+1-4ubuntu2) vivid; urgency=medium

  * debian/patches/0015-Work-around-flaky-XIM-modules.patch,
    debian/patches/0016-Improve-XIC-fix.patch,
    debian/patches/0017-Further-improve-create_frame_xic-patch.patch,
    debian/patches/0018-Further-improve-XIM-init.patch:
    Apply upstream patches to make Emacs work with IBus and UIM.
    (Closes: #753534) (LP: #493766)
 -- Anders Kaseorg <email address hidden> Thu, 28 Aug 2014 06:57:06 -0400

Changed in emacs24 (Ubuntu):
status: Confirmed → Fix Released
Anders Kaseorg (andersk) wrote :

Merge prepared at bug 1387323.

Bruno Beaufils (beaufils) wrote :

As for upgrading today unfortunately utopic unicorn (14.10) seems not distribute 24.3+1-4ubuntu2 but 24.3+1-4ubuntu1, for which this bug is still present.

What is the best way to install 24.3+1-4ubuntu2 ?

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.

Changed in emacs23 (Fedora):
importance: Unknown → Medium
status: Unknown → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.