GNU bug report logs - #60711
Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

Previous Next

Full log

Message #23 received at 60711 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 60711 <at> debbugs.gnu.org, Marcin Kasperski <Marcin.Kasperski <at> mekk.waw.pl>
Subject: Re: bug#60711: Compose fails to generate ≤ and
 ≥ (only those two! and only in emacs!)
Date: Wed, 11 Jan 2023 18:21:12 +0800

Gregory Heytings <gregory <at> heytings.org> writes:

>>> It's unlikely that this is an Emacs bug, Emacs does not "see"
>>> anything until the compose sequence is finished, it only sees the
>>> final character.
>>
>> Not exactly true.
>>
>
> Marcin explicitly said he uses the Compose key, with both Emacs and
> other apps, and not an input method with Emacs.  And as far as I know
> when the Compose key is used apps only receive the final character.

The compose key requires either compose state to be kept by the program
in cooperation with XLookupString, or is implemented by the input
method.  In either case the program must keep compose state around
explicitly, or forward the compose key events to the input method, which
will then indicate to the program that it will do its own internal
processing of the compose key sequence and that the program should
ignore the key itself.

If you don't believe me, run xev (or xinput test-xi2) on a system that
has compose set up and enter a compose sequence.  You will see the
(XI_)KeyPress and KeyRelease events with either 0 bytes returned from
X(mb)LookupString or True returned from XFilterEvent.

If a pop up window shows up, then it is definitely being displayed by
an input method.  Xlib itself does not know how to do that.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.