Bug 479336 - Emacs does not handle <Multi_Key>
Emacs does not handle <Multi_Key>
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: libX11 (Show other bugs)
19
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: i18n, Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-08 17:36 EST by Johan Vromans
Modified: 2015-02-18 06:58 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 06:58:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xorg. conf (307 bytes, text/plain)
2009-01-23 13:19 EST, Johan Vromans
no flags Details
Xorg.0.log (49.04 KB, text/plain)
2009-01-23 13:19 EST, Johan Vromans
no flags Details
sample program (4.87 KB, text/plain)
2009-04-14 22:39 EDT, Akira TAGOH
no flags Details

  None (edit)
Description Johan Vromans 2009-01-08 17:36:43 EST
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.
Comment 1 Johan Vromans 2009-01-11 17:00:17 EST
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.
Comment 2 Daniel Novotny 2009-01-22 08:25:37 EST
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)
Comment 3 Johan Vromans 2009-01-22 12:28:09 EST
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.
Comment 4 Daniel Novotny 2009-01-23 05:19:42 EST
(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
Comment 5 Matěj Cepl 2009-01-23 11:46:06 EST
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.
Comment 6 Johan Vromans 2009-01-23 13:18:20 EST
(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.
Comment 7 Johan Vromans 2009-01-23 13:19:04 EST
Created attachment 329863 [details]
xorg. conf
Comment 8 Johan Vromans 2009-01-23 13:19:49 EST
Created attachment 329864 [details]
Xorg.0.log
Comment 9 Anders 2009-03-20 05:59:37 EDT
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.
Comment 10 Johan Vromans 2009-04-14 16:44:27 EDT
See also https://bugzilla.redhat.com/show_bug.cgi?id=493172
Comment 11 Akira TAGOH 2009-04-14 22:39:46 EDT
Created attachment 339606 [details]
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.
Comment 12 Akira TAGOH 2009-04-14 22:43:18 EDT
forgot to mention this. when it happens on emacs, XIM doesn't work either due to a fail of XCreateIC.
Comment 13 Matěj Cepl 2009-04-16 04:07:20 EDT
Throwing in hopefully better direction and putting Peter on CC list.
Comment 14 Bug Zapper 2009-11-18 05:42:09 EST
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
Comment 15 Bug Zapper 2009-12-18 02:33:05 EST
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.
Comment 16 Peter Oliver 2013-10-18 12:53:22 EDT
I still see these symptoms with emacs-24.3-11.fc19.i686 and environment variable XMODIFIERS set to the now-default "@im=ibus".
Comment 17 Akira TAGOH 2013-10-21 03:42:30 EDT
maybe better mention your locale for information I guess.
Comment 18 Johan Vromans 2013-10-21 04:14:18 EDT
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.)
Comment 19 Akira TAGOH 2013-10-21 06:07:38 EDT
(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
Comment 20 Peter Oliver 2013-10-22 14:09:17 EDT
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.
Comment 21 Peter Oliver 2014-04-07 14:32:55 EDT
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.
Comment 22 Fedora End Of Life 2015-01-09 16:38:06 EST
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.
Comment 23 Fedora End Of Life 2015-02-18 06:58:24 EST
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.

Note You need to log in before you can comment on or make changes to this bug.