bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Marcin Kasperski]

I heavily use compose sequences while writing („CapsLock - >” – and I
get nice  „→”).

Since some recent emacs update (version below):

a) I can no longer generate ≤ and ≥ in Emacs

    All combinations (Compose >=, Compose >_, Compose _>) end the same:
    - after entering Compose > there is floating window hinting ≥
    - once I type =, puff, no character in the buffer, nothing.

b) Other Compose combinations I tried work.

    In particular Compose => works in Emacs and generates ⇒,
    Compose > > makes », Compose - > makes → and so on

    (can't guarantee everything works  but from dozens of combinations
    I use I found only those two to be problematic).

c) In all other applications ≥ and ≤ are properly generated with compose
    (tried gedit, terminator, firefox, vscode …)

So, for example, pressing
      a Compose < = b Compose < < c
in gedit/code/firefox results in
      a≤b«c
while in Emacs results in
      ab«c
(and really that, I tried saving file and hex-inspecting it, no
invisible character there).


Problem appeared after some recent update (most likely after I upgraded
to emacs 28 but I am not 100% sure, could be also related to Ubuntu
upgrade).

Problem reproduces in `emacs -Q`

Version I use now:

GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
cairo version 1.16.0)
 of 2022-05-31

(Ubuntu 22.04.1 LTS,
 emacs from ppa https://launchpad.net/~kelleyk/+archive/ubuntu/emacs,
 KDE Plasma as window manager)

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Marcin Kasperski]

One more note: copy&paste of ≤ and ≥ to emacs works, those letters are
then properly displayed, saved, etc.

wt., 10 sty 2023 o 16:13 Marcin Kasperski
<Marcin.Kasperski@mekk.waw.pl> napisał(a):
>
> I heavily use compose sequences while writing („CapsLock - >” – and I
> get nice  „→”).
>
> Since some recent emacs update (version below):
>
> a) I can no longer generate ≤ and ≥ in Emacs
>
>     All combinations (Compose >=, Compose >_, Compose _>) end the same:
>     - after entering Compose > there is floating window hinting ≥
>     - once I type =, puff, no character in the buffer, nothing.
>
> b) Other Compose combinations I tried work.
>
>     In particular Compose => works in Emacs and generates ⇒,
>     Compose > > makes », Compose - > makes → and so on
>
>     (can't guarantee everything works  but from dozens of combinations
>     I use I found only those two to be problematic).
>
> c) In all other applications ≥ and ≤ are properly generated with compose
>     (tried gedit, terminator, firefox, vscode …)
>
> So, for example, pressing
>       a Compose < = b Compose < < c
> in gedit/code/firefox results in
>       a≤b«c
> while in Emacs results in
>       ab«c
> (and really that, I tried saving file and hex-inspecting it, no
> invisible character there).
>
>
> Problem appeared after some recent update (most likely after I upgraded
> to emacs 28 but I am not 100% sure, could be also related to Ubuntu
> upgrade).
>
> Problem reproduces in `emacs -Q`
>
> Version I use now:
>
> GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
> cairo version 1.16.0)
>  of 2022-05-31
>
> (Ubuntu 22.04.1 LTS,
>  emacs from ppa https://launchpad.net/~kelleyk/+archive/ubuntu/emacs,
>  KDE Plasma as window manager)

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]


>
> Since some recent emacs update (version below):
>
> a) I can no longer generate ≤ and ≥ in Emacs
>
> All combinations (Compose >=, Compose >_, Compose _>) end the same:
> - after entering Compose > there is floating window hinting ≥
> - once I type =, puff, no character in the buffer, nothing.
>

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.

What's that "floating window" you mention?

What does Emacs tell you when you type "C-h k Compose _ >"?

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Eli Zaretskii]

> Cc: 60711@debbugs.gnu.org
> Date: Tue, 10 Jan 2023 16:01:35 +0000
> From: Gregory Heytings <gregory@heytings.org>
> 
> 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.
> 
> What's that "floating window" you mention?
> 
> What does Emacs tell you when you type "C-h k Compose _ >"?

And also what does "C-h l" show _after_ you type those?

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> Since some recent emacs update (version below):
>>
>> a) I can no longer generate ≤ and ≥ in Emacs
>>
>> All combinations (Compose >=, Compose >_, Compose _>) end the same:
>> - after entering Compose > there is floating window hinting ≥
>> - once I type =, puff, no character in the buffer, nothing.
>>
>
> 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.

Composition involves a whole bunch of code in xterm.c.  I guess these
days composition is mostly implemented in an input method, so all the
communication with the input method (forwarding and waiting for events,
for example) implemented in xterm.c and Xlib is also suspect.

> What's that "floating window" you mention?
>
> What does Emacs tell you when you type "C-h k Compose _ >"?

So if this doesn't show anything meaningful, would you please see what
KeyPress events are received by Emacs while you are typing the compose
sequence, and after _> should have been inserted?  (Place the breakpoint
in handle_one_xevent, because at that point events have already been
filtered.  This is assuming you're really using Emacs 28.1, of course.
The code has been rewritten in Emacs 29.)

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Gregory Heytings]

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

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Gregory Heytings <gregory@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.

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Marcin Kasperski]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

(summary reply)

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

As I said, I tried in gedit, vscode, firefox, terminator, … –
everywhere this compose clause works. Only emacs fails. And only on
those two sequences.  Considering it fails whichever compose method I
use, I suppose it may have problem with the final char. But note that
copy&paste of the same char works.


> What's that "floating window" you mention?

Attached as floating-window.png (this is what I see after Compose >)


> What does Emacs tell you when you type "C-h k Compose _ >"?

Nothing. It still waits displaying prompt „Describe the following key…"
Same for Compose >= etc.
But when I enter  Compose -> (which work) it displays info about
self-insert-command


> And also what does "C-h l" show _after_ you type those?

…
 <return>                ;; newline
 C-h l                    ;; view-lossage

(I typed this sequence after pressing return)


> Place the breakpoint in handle_one_xevent…

Unfortunately I don't compile emacs myself and don't really have
experience debugging on such level.

[-- Attachment #2: floating-window.png --]
[-- Type: image/png, Size: 6505 bytes --]

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Marcin Kasperski]

[-- Attachment #1: Type: text/plain, Size: 190 bytes --]

… and for what it is worth it …

Emacs (emacs -Q) on the left, gedit on the right.

Over both windows I repeated the same keystrokes:

a Compose > = b Compose < = c Compose = > d

[-- Attachment #2: emacs-and-gedit.png --]
[-- Type: image/png, Size: 15725 bytes --]

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Marcin Kasperski]

Result from `xev -event keyboard` when I typed
     a Compose > = b
over its window

KeyRelease event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212090489, (67,94), root:(2163,1144),
   state 0x10, keycode 38 (keysym 0x61, a), same_screen YES,
   XLookupString gives 1 bytes: (61) "a"
   XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212091824, (67,94), root:(2163,1144),
   state 0x10, keycode 66 (keysym 0xff20, Multi_key), same_screen YES,
   XLookupString gives 0 bytes:
   XmbLookupString gives 0 bytes:
   XFilterEvent returns: True

KeyRelease event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212091968, (67,94), root:(2163,1144),
   state 0x10, keycode 66 (keysym 0xff20, Multi_key), same_screen YES,
   XLookupString gives 0 bytes:
   XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212093128, (67,94), root:(2163,1144),
   state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
   XLookupString gives 0 bytes:
   XmbLookupString gives 0 bytes:
   XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212093240, (67,94), root:(2163,1144),
   state 0x11, keycode 60 (keysym 0x3e, greater), same_screen YES,
   XLookupString gives 1 bytes: (3e) ">"
   XmbLookupString gives 1 bytes: (3e) ">"
   XFilterEvent returns: True

KeyRelease event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212093376, (67,94), root:(2163,1144),
   state 0x11, keycode 60 (keysym 0x3e, greater), same_screen YES,
   XLookupString gives 1 bytes: (3e) ">"
   XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212093424, (67,94), root:(2163,1144),
   state 0x11, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
   XLookupString gives 0 bytes:
   XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212093888, (67,94), root:(2163,1144),
   state 0x10, keycode 21 (keysym 0x3d, equal), same_screen YES,
   XLookupString gives 1 bytes: (3d) "="
   XmbLookupString gives 1 bytes: (3d) "="
   XFilterEvent returns: True

KeyPress event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212093888, (67,94), root:(2163,1144),
   state 0x10, keycode 0 (keysym 0x1002265, U2265), same_screen YES,
   XLookupString gives 0 bytes:
   XmbLookupString gives 3 bytes: (e2 89 a5) "≥"
   XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212094008, (67,94), root:(2163,1144),
   state 0x10, keycode 21 (keysym 0x3d, equal), same_screen YES,
   XLookupString gives 1 bytes: (3d) "="
   XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212094952, (67,94), root:(2163,1144),
   state 0x10, keycode 56 (keysym 0x62, b), same_screen YES,
   XLookupString gives 1 bytes: (62) "b"
   XmbLookupString gives 1 bytes: (62) "b"
   XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x8a00001,
   root 0x294, subw 0x0, time 3212095048, (67,94), root:(2163,1144),
   state 0x10, keycode 56 (keysym 0x62, b), same_screen YES,
   XLookupString gives 1 bytes: (62) "b"
   XFilterEvent returns: False

śr., 11 sty 2023 o 19:49 Marcin Kasperski
<Marcin.Kasperski@mekk.waw.pl> napisał(a):
>
> … and for what it is worth it …
>
> Emacs (emacs -Q) on the left, gedit on the right.
>
> Over both windows I repeated the same keystrokes:
>
> a Compose > = b Compose < = c Compose = > d

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Marcin Kasperski]

And some additional remarks:

a) I forgot to mention that this small window popped up by emacs is
emacs-specific. gedit or firefox hint composition in progress
differently (displaying preliminary character in-place).

Still, I suppose the problem is somewhere on the very end, when final
ready character is to be consumed, and this window need not be
directly related.

b) I downloaded emacs27.1 and emacs26.3 (versions from 20.04 from
https://launchpad.net/~kelleyk/+archive/ubuntu/emacs/+packages and
https://launchpad.net/~kelleyk/+archive/ubuntu/emacs/+sourcepub/10887371/+listing-archive-extra
) and problem is present in both.

    I am practically sure that I was happily using emacs26 entering
those sequences for noticeable time, so it looks like it is not about
emacs change but about emacs interaction with upgraded environment (=
most likely emacs @ Ubuntu 20.04 works, emacs @ Ubuntu 22.04 has the
composition problem I describe)

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Eli Zaretskii]

> Cc: 60711@debbugs.gnu.org, Gregory Heytings <gregory@heytings.org>
> From: Marcin Kasperski <Marcin.Kasperski@mekk.waw.pl>
> Date: Wed, 11 Jan 2023 19:45:25 +0100
> 
> > And also what does "C-h l" show _after_ you type those?
> 
> …
>  <return>                ;; newline
>  C-h l                    ;; view-lossage
> 
> (I typed this sequence after pressing return)

Which AFAIU means Emacs didn't receive any character input for your
composed sequence, none at all.

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]


>> What's that "floating window" you mention?
>
> Attached as floating-window.png (this is what I see after Compose >)
>

That doesn't seem to be an Emacs thing.  Do you see the same floating 
window with other apps?  Do you by chance know the name of the app that 
displays that floating window?

>> What does Emacs tell you when you type "C-h k Compose _ >"?
>
> Nothing. It still waits displaying prompt „Describe the following key…" 
> Same for Compose >= etc.
>
> But when I enter Compose -> (which work) it displays info about 
> self-insert-command
>
>> And also what does "C-h l" show _after_ you type those?
>
> …
> <return>                ;; newline
> C-h l                    ;; view-lossage
>
> (I typed this sequence after pressing return)
>

As Eli just said, it means that Emacs didn't receive any character.

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Gregory Heytings]

>
> The compose key requires either compose state to be kept by the program 
> in cooperation with XLookupString, or is implemented by the input 
> method.
>

You're right.  I thought this was happening entirely inside Xlib, and 
indeed it requires some cooperation of the program.  It seems that this 
cooperation is minimal, though: IIUC, the client should just immediately 
discard the events when XFilterEvent returns True, that is, until the 
composed character is delivered.

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Gregory Heytings]

>
> Result from `xev -event keyboard` when I typed
>     a Compose > = b
> over its window
>

I see the same sequence of events here.

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Gregory Heytings]

>
> a) I forgot to mention that this small window popped up by emacs is 
> emacs-specific. gedit or firefox hint composition in progress 
> differently (displaying preliminary character in-place).
>

This answers one of my questions.  But... are you sure that you don't see 
that same window in any other app?  I don't think it's something displayed 
by Emacs.  AFAIK you should not see anything while typing a compose 
sequence.  Here at least nothing is displayed, the cursor just continues 
to blink.

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Andreas Schwab]

On Jan 11 2023, Gregory Heytings wrote:

> This answers one of my questions.  But... are you sure that you don't see
> that same window in any other app?  I don't think it's something displayed
> by Emacs.

This is typically done by the input method, probably IBus.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> The compose key requires either compose state to be kept by the
>> program in cooperation with XLookupString, or is implemented by the
>> input method.
>>
>
> You're right.  I thought this was happening entirely inside Xlib, and
> indeed it requires some cooperation of the program.  It seems that
> this cooperation is minimal, though: IIUC, the client should just
> immediately discard the events when XFilterEvent returns True, that
> is, until the composed character is delivered.

How do you think ``the composed character is delivered''?

Marcin, would you please put a breakpoint under the "KeyPress:" label in
handle_one_xevent, and set it to run (upon being hit):

  p event->xkey

What do you see when you finish typing the compose sequence that does
not work?

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Marcin Kasperski]

> > a) I forgot to mention that this small window popped up by emacs is
> > emacs-specific. gedit or firefox hint composition in progress
> > differently (displaying preliminary character in-place).
>
> This answers one of my questions.  But... are you sure that you don't see
> that same window in any other app?

I don't. Of course I can't claim I tested this thoroughly, but no app
I typically use to write text displays stt similar.

My bet is that there are various APIs which could be used and this is
behaviour of some API emacs uses (at least in this build and in this
environment). I didn't see this popup „before problem started” (on
older Ubuntu) – then IIRC emacs composition worked silently, character
appeared only once fully entered.

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Marcin Kasperski]

Half-eureka.

I found another application which also exhibits problematic behaviour
(fails to display ≥ / ≤  and shows this strange popup).

xterm

At the same time gnome-terminal, konsole, terminator, xfce4-terminal are OK,
compose works properly in them and there is no popup.

So looks like „raw” X11 somehow misworks, while every desktop API
manages to smooth it towards proper behaviour.

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]


>
> My bet is that there are various APIs which could be used and this is 
> behaviour of some API emacs uses (at least in this build and in this 
> environment). I didn't see this popup „before problem started” (on older 
> Ubuntu) – then IIRC emacs composition worked silently, character 
> appeared only once fully entered.
>

Can you perhaps try to play with the various values of the inputStyle X 
resource, by starting Emacs like this:

emacs --xrm 'Emacs.inputStyle: callback'
emacs --xrm 'Emacs.inputStyle: offthespot'
emacs --xrm 'Emacs.inputStyle: overthespot'
emacs --xrm 'Emacs.inputStyle: none'
emacs --xrm 'Emacs.inputStyle: root'
emacs --xrm 'Emacs.inputStyle: native'

Does one of these invocations solve your problem?

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Marcin Kasperski <Marcin.Kasperski@mekk.waw.pl> writes:

> Half-eureka.
>
> I found another application which also exhibits problematic behaviour
> (fails to display ≥ / ≤  and shows this strange popup).

The ``strange popup'' is being displayed by the input method because the
default overTheSpot input style used by xterm does not support preedit
callbacks.

> xterm
>
> At the same time gnome-terminal, konsole, terminator, xfce4-terminal are OK,
> compose works properly in them and there is no popup.
>
> So looks like „raw” X11 somehow misworks, while every desktop API
> manages to smooth it towards proper behaviour.

This is because the other programs use the input method module developed
by the input method developers for the toolkits they use: GTK+ and Qt.

In Emacs 29, there is an option to use them in Emacs as well: just turn
on `x-gtk-use-native-input'.

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]


>> You're right.  I thought this was happening entirely inside Xlib, and 
>> indeed it requires some cooperation of the program.  It seems that this 
>> cooperation is minimal, though: IIUC, the client should just 
>> immediately discard the events when XFilterEvent returns True, that is, 
>> until the composed character is delivered.
>
> How do you think ``the composed character is delivered''?
>

Like any other character, with a KeyPress event, but through 
XmbLookupString (its first occurrence in handle_one_xevent).  AFAIU what 
happens is this:

Compose -> KeyPress event, keysym Multi_key, with XFilterEvent True
_       -> KeyPress event, keysym underscore, with XFilterEvent True
>       -> KeyPress event, keysym greater, with XFilterEvent True

after which a KeyPress event, keysym U2265, with XFilterEvent False, and 
for which XmbLookupString returns "≥", is delivered to the client.

What am I missing?

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Gregory Heytings <gregory@heytings.org> writes:

> Compose -> KeyPress event, keysym Multi_key, with XFilterEvent True
> _       -> KeyPress event, keysym underscore, with XFilterEvent True
>>       -> KeyPress event, keysym greater, with XFilterEvent True
>
> after which a KeyPress event, keysym U2265, with XFilterEvent False,
> and for which XmbLookupString returns "≥", is delivered to the client.
>
> What am I missing?

The part where XmbLookupString returns the correct character.  In
addition, the input method may chose to commit a string without a key
event.  This results in an XIM_COMMIT event being sent from the input
method with a string, which, in one of the worst misdesigns ever, makes
Xlib put back a fake key event onto the event queue, then stash the
string somewhere, and return it upon the next call to XmbLookupString.

What input method framework are you using, and what is Marcin using?
And, Marcin, what is the value of locale-coding-system?  If you put a
breakpoint on xim_open_dpy, then type:

  p XLocaleOfIM (xim)

after XOpenIM is called, what is the locale returned there?  What events
do you get when you complete the composition?

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Gregory Heytings]

>
> The part where XmbLookupString returns the correct character.
>

What do you mean?  Conceptually the code does this:

while (XPending (display))
   {
     XNextEvent (display, &event);
     if (XFilterEvent (&event, None) == True)
       continue;
     if (event.type == KeyPress)
       {
         XmbLookupString(input_context, &event.xkey, buffer, sizeof (buffer) - 1, &keysym, &status);
         if (status == XLookupChars)
           {
             /* do something with buffer */
           }
       }
   }

There is nothing that must be kept around in that code.

>
> In addition, the input method may chose to commit a string without a key 
> event.  This results in an XIM_COMMIT event being sent from the input 
> method with a string, which, in one of the worst misdesigns ever, makes 
> Xlib put back a fake key event onto the event queue, then stash the 
> string somewhere, and return it upon the next call to XmbLookupString.
>

I'm sure there are possible complications, but AFAIU they do not change 
the pattern outlined above.

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Gregory Heytings <gregory@heytings.org> writes:

> What do you mean?  Conceptually the code does this:
>
> while (XPending (display))
>   {
>     XNextEvent (display, &event);
>     if (XFilterEvent (&event, None) == True)
>       continue;
>     if (event.type == KeyPress)
>       {
>         XmbLookupString(input_context, &event.xkey, buffer, sizeof (buffer) - 1, &keysym, &status);
>         if (status == XLookupChars)
>           {
>             /* do something with buffer */
>           }
>       }
>   }
>
> There is nothing that must be kept around in that code.

Where do you think the text that is stored in buffer comes from?  And
what if the input method choses to commit a keysym?

What if the Xlib character encoding routines do not understand that
particular character?

> I'm sure there are possible complications, but AFAIU they do not
> change the pattern outlined above.

If you get XLookupChars, then half the time the key event you receive is
not a real key event.  Many things can go wrong there, so it is
impossible to debug this without knowing exactly what events are being
sent.

bug#60711: Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)

[Gregory Heytings]

During a private exchange, the OP confirmed that this bug is fixed in 
Emacs 29 (with x-gtk-use-native-input set to t).

Closing.