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.

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

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

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.)

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+debian@iki.fi>:

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.

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.

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

Hello,

I just happened to me on Emacs 1:30.1+1-2 (unstable).

I have to set the environment variable XMODIFIERS to empty string to get it working.

I have no explanation for this behavior as it was working previously.

Regards