--- Begin Message ---
|
Subject: |
29.0.50; PGTK degrades to terminal-compatible keyboard events |
|
Date: |
Thu, 26 May 2022 07:43:37 -0700 |
Meaningful control keys in ASCII are @, A-Z, [ \ ] ^ and _ (0x40 through
0x5f). VT100 terminals use the Control key to zero-out the top two bits
of seven, leaving us with 2^5=32 characters. The above control keys
happen to be a bank of 32 that are all graphical and easy to reach.) I
have old notes to myself that say that VT100 terminals do a little extra
mapping: Control and `?' (0x3f) sends the DEL keycode (0xff); Emacs
itself seems to map Control and `/' (0x2f) to the same keycode as
Control and `_' (0x1f)).
Window system interfaces like GTK track individual keypresses, and Emacs
supports binding other keys with Control:
(global-set-key [(control ?<)] 'my-left-command)
(global-set-key [(control ?>)] 'my-right-command)
Some terminals even send special character sequences to Emacs that
encode the Control modifier alongside the ">" character. Xterm is one
of those, if you use the "xterm" terminal type.
I was experimenting with Emacs configurations (in a weekly snapshot) and
discovered that the PGTK interface does not support arbitrary Control
modifiers. I can send any of the ASCII control keys listed above, but
for all others PGTK ignores the Control modifier. Control-> turns into
a plain ">", for example.
These configuration options have the bug:
--with-x-toolkit=gtk3
--with-xwidgets=yes
--with-pgtk=yes
These configuration options understand Control-> correctly.
--with-x-toolkit=gtk3
--with-xwidgets=yes
--with-pgtk=no
I'm aware that PGTK is under active development and unreliable, and the
immediate workaround is "stop using PGTK".
Derek
--
Derek Upham
derek_upham@mailfence.com
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#55362: 29.0.50; Super key no longer works on Wayland |
|
Date: |
Mon, 10 Oct 2022 11:08:35 +0800 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) |
Po Lu <luangruo@yahoo.com> writes:
> Not before Emacs 29 is released, or otherwise the GTK developers will
> never fix their thing, and we will be stuck maintaining yet another
> broken hack to work around one of their bugs until the end of time,
> which is several degrees of magnitude more confusing because we now have
> two configurations where sometimes identical, and sometimes different
> GTK bugs have to be worked around.
And the bug has now been fixed in GTK. The fix should be released and
reach most users rather quickly, so I'm closing this bug.
--- End Message ---