GNU bug report logs -
#60711
Compose fails to generate ≤ and ≥ (only those two! and only in emacs!)
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60711 in the body.
You can then email your comments to 60711 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Tue, 10 Jan 2023 15:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Marcin Kasperski <Marcin.Kasperski <at> mekk.waw.pl>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 10 Jan 2023 15:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Tue, 10 Jan 2023 15:17:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Tue, 10 Jan 2023 16:02:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 60711 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> 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 _ >"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Tue, 10 Jan 2023 17:08:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 60711 <at> debbugs.gnu.org (full text, mbox):
> Cc: 60711 <at> debbugs.gnu.org
> Date: Tue, 10 Jan 2023 16:01:35 +0000
> From: Gregory Heytings <gregory <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 07:30:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 60711 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> 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.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 08:46:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 60711 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 10:22:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 60711 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 18:46:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 60711 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
(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.
[floating-window.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 18:50:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 60711 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
… 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
[emacs-and-gedit.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 18:55:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 60711 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 19:19:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 60711 <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 20:01:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 60711 <at> debbugs.gnu.org (full text, mbox):
> Cc: 60711 <at> debbugs.gnu.org, Gregory Heytings <gregory <at> heytings.org>
> From: Marcin Kasperski <Marcin.Kasperski <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 21:00:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 60711 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 21:03:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 60711 <at> debbugs.gnu.org (full text, mbox):
>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 21:12:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 60711 <at> debbugs.gnu.org (full text, mbox):
>
> Result from `xev -event keyboard` when I typed
> a Compose > = b
> over its window
>
I see the same sequence of events here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 21:16:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 60711 <at> debbugs.gnu.org (full text, mbox):
>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Wed, 11 Jan 2023 23:06:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 60711 <at> debbugs.gnu.org (full text, mbox):
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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Thu, 12 Jan 2023 01:26:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 60711 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Fri, 13 Jan 2023 14:27:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 60711 <at> debbugs.gnu.org (full text, mbox):
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Fri, 13 Jan 2023 14:42:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 60711 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Sat, 14 Jan 2023 21:55:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 60711 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Sun, 15 Jan 2023 00:38:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 60711 <at> debbugs.gnu.org (full text, mbox):
Marcin Kasperski <Marcin.Kasperski <at> 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'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Mon, 16 Jan 2023 09:42:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 60711 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Mon, 16 Jan 2023 09:58:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 60711 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Mon, 16 Jan 2023 12:32:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 60711 <at> debbugs.gnu.org (full text, mbox):
>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60711
; Package
emacs
.
(Tue, 17 Jan 2023 00:42:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 60711 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> 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.
Reply sent
to
Gregory Heytings <gregory <at> heytings.org>
:
You have taken responsibility.
(Thu, 09 Feb 2023 11:02:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Marcin Kasperski <Marcin.Kasperski <at> mekk.waw.pl>
:
bug acknowledged by developer.
(Thu, 09 Feb 2023 11:02:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 60711-done <at> debbugs.gnu.org (full text, mbox):
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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 09 Mar 2023 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 48 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.