Bug#958784: emacs: Compose key fails with "<Multi_key> is undefined" if XMODIFIERS is set

[Melissa Boiko]

Package: emacs
Version: 1:26.1+1-3.2+deb10u1
Severity: normal

The variable XMODIFIERS is necessary to use input methods (e.g. for
Japanese, Chinese, or the International Phonetic Alphabet) in Emacs.

The Compose key, called Multi_key in X terminology, is used to enter
international characters in general.

These two mechanisms appear to conflict in Emacs (and only in Emacs).
If I set my XMODIFIERS (I tried with XMODIFIERS="@im=uim" and
XMODIFIERS="@im=xim"), the Multi_key stops working for character input,
instead making Emacs complain that "<Multi_key> is undefined".

If I unset XMODIFIERS the Multi_key works, but then I can’t use external
input methods.

This bug is a recurrent issue with Emacs, and several reports from past
years can be found online (see e.g. thread in
https://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00867.html ).
It appeared to be solved for a while on my system, so it may be a
regression. I’m reporting for the Debian stable version, but I tried
an Emacs 28 snapshot package and found the same behaviour. It happens for
both emacs-gtk and lucid. There was a time when you could work around it
(for some reason) by setting your LC_ALL=ja_JP.UTF-8, but this doesn’t
work anymore.

I would appreciate any current workarounds, because this bug renders Emacs
unusable for my case (I’m a linguist writing my thesis in Latex using
Japanese, IPA and other writing systems).

Thank you for your attention and hard work.

-- System Information:
Debian Release: 10.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs depends on:
ii emacs-gtk 1:26.1+1-3.2+deb10u1

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

[era]

On Sat, Apr 25, 2020, at 12:09, Melissa Boiko wrote:
> I would appreciate any current workarounds, because this bug renders Emacs
> unusable for my case (I’m a linguist writing my thesis in Latex using
> Japanese, IPA and other writing systems).

The documentation in the Debian wiki suggests using alternative means for Japanese input specifically with Emacs.

https://wiki.debian.org/JapaneseEnvironmentE currently says

> emacs has its own unique Japanese input infrastructure (egg etc.)
> which does not rely on external programs such as X nor FEP.
>
> If you wish to input without going through XIM, set XMODIFIERS value
> to "none" while starting emacs. From shell, execute as:
> $ XMODIFIERS=none emacs

I'm not familiar enough with these things to tell whether the information there is current and accurate, but it came up as I was figuring out these things.

(I don't think I can solve your problem; I was just figuring out what it would take for someone who - like myself - is unfamiliar with IME etc to repro. Perhaps it would be useful to summarize how your system is configured and what keystrokes and perhaps mouse clicks it requires to correctly input an IPA symbol like ʃ (U+0283) when this bug is fixed.)

--
If this were a real .signature, it would suck less. Well, maybe not.

[Melissa Boiko]

Right, that’s one workaround; you can emacs-specific input methods in a pinch.  But it’s not so nice since you have to duplicate your configuration, keyboard settings, user dictionaries etc. And IMEs are self-learning systems, so it’s a bit of a shame to split their training.

---

I was wrong in thinking this was a regression. Rather, what triggered it was the uim-xim daemon not running (seems like some upgrade broke my X init scripts—is it just me or gnome is making it harder and harder to just run a command at startup?).

I would still consider this a bug (Multi_key should work regardless) but it’s an edge case, since usually IME users will need the daemon running anyway.

Here are some steps to reproduce:

1. Assign a key to Multi_key using xmodmap (if you're on Xorg; if on Wayland, do whatever they do to assign a Compose key). On my keyboard, "xmodmap -e 'keycode 135' = Multi_key" will assign the "menu" key to it. (xev(1) can tell the keycode number of a key.)

2. Test it elsewhere; e.g. <Multi_key s s> should output 'ß'.

3. env XMODIFIERS= emacs -q; test Multi_key (in my system it works).

4. Without the IME daemon running, env XMODIFIERS=@im=uim emacs -q (here this breaks Multi_key support.)

5. uim-xim &; retry last command (now Multi_key works again).

Experimentally, I note that setting XMODIFIERS=@im=asdfg (or any other garbage) will also trigger the bug, but not XMODIFIERS=asdfg or XMODIFIERS=@foo=bar.  So it seems like it's specifically the @im= modifier that may cause problems.

Warm regards,

--

Melissa

2020年4月25日(土) 14:03 era <era+d...@iki.fi>:

[era]

On Mon, Apr 27, 2020, at 11:49, Melissa Boiko wrote:
> I was wrong in thinking this was a regression. Rather, what triggered
> it was the uim-xim daemon not running (seems like some upgrade broke my
> X init scripts—is it just me or gnome is making it harder and harder to
> just run a command at startup?).

Not really an Emacs bug then, and seems rather vague for reassigning to Gnome or whatever.

I was under the impression that the recommended way to start an input method is to click and drool somewhere deep within the Gnome internationalization and accessibility options, rather than explicitly start a program at session login.

https://wiki.archlinux.org/index.php/IBus#GNOME has some guidance, though it's obviously for Arch, not Debian.

https://wiki.debian.org/InputMethodBuster suggests running im-config as a prerequisite (probably not necessary here?) then using Gnome Settings > Region & Languages > Input Sources

Sorry if this is misleading, irrelevant, or trivial.

[Stéphane Chauveau]

I just noticed that problem yesterday with emacs-gtk and I want to point
out that the feature/pgtk (Pure GTK) branch of emacs does not seem to be
affected.

This new emacs-pgtk is a true GTK3 application unlike the old emacs-gtk
which is an X11 app using GTK widgets (see
https://emacshorrors.com/posts/psa-emacs-is-not-a-proper-gtk-application.html).

The branch can be found in
http://git.savannah.gnu.org/cgit/emacs.git/log/?h=feature/pgtk or
https://github.com/emacs-mirror/emacs/tree/feature/pgtk

As far as I can tell, this new backend is working fine. You may have to
update your .emacs if it relies on some X11 specific features (e.g. such
as comparing window-system to 'x). Apart from fixing a few integration
issues such as this one, another advantage of a pure gtk build is that
it can run as a native Wayland application.

Hopefully, it will be officially included soon in emacs.

[Julien Palard]

Hi,

Just happened to me (2022-04) with emacs 27.1 and gnome 42.

I don't know exactly when it happened and did not find something relevant in my /var/log/apt/history.log.

What I know is that it worked since like a year, until a bunch of days, today I have:

$ emacs # No compose key, shows <Multi_key is undefined>
$ env | grep MODIFIERS
XMODIFIERS=@im=ibus
$ XMODIFIERS= emacs # Compose key works

But I remember when it worked it was displaying a little bubble, during the composition, telling me what I was composing. Using an empty XMODIFIERS it does not display the bubble (but the composition happen properly), hope it speaks to someone.

Bests,
-- 
Julien Palard
https://mdk.fr