GNU bug report logs -
#52795
29.0.50; pgtk: issues with key bindings
Previous Next
To reply to this bug, email your comments to 52795 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52795
; Package
emacs
.
(Sat, 25 Dec 2021 18:01:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 25 Dec 2021 18:01:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello folks,
tl;dr: right now, --with-pgtk, I must choose between:
- by default, Emacs not recognizing S-SPC: C-h k seems to think I only
hit SPC; or
- calling (pgtk-use-im-context nil), which gets me S-SPC back, but makes
dead keys ineffectual: I can no longer input combining diacritics and
type in "â", "ë", "ñ" and such.
I observe this on all my setups:
- GNOME on Ubuntu 20.04,
- XFCE on Debian 11,
- Plasma on openSUSE Tumbleweed.
On all of these, Emacs's "classical" X11+GTK configuration works fine;
other applications work fine too; the problems I describe only show up
in Emacs compiled --with-pgtk.
Is there a knob to tweak that I've missed? I've seen other reports of
input problems with the pgtk configuration, but I don't think I found
any insight into my specific issue.
Let me know if there are additional details I should provide about my
setups. Since all other applications behave fine (including Emacs
configured with X11+GTK), I'm assuming this is a problem with this new
feature, rather than an issue with my DE/window manager/ibus settings?
Thank you for your time.
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
of 2021-12-22 built on hirondell
Repository revision: 5b0121b708986c836fa970b800387363806a035a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
Configured using:
'configure --with-xwidgets --with-cairo --with-gconf --with-xinput2'
Configured features:
ACL CAIRO DBUS FREETYPE GCONF GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52795
; Package
emacs
.
(Sun, 26 Dec 2021 01:34:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 52795 <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> On all of these, Emacs's "classical" X11+GTK configuration works fine;
> other applications work fine too; the problems I describe only show up
> in Emacs compiled --with-pgtk.
WDYM by other applications? Are those GTK+ applications, and do they
treat S-SCP differently from SPC?
> Is there a knob to tweak that I've missed? I've seen other reports of
> input problems with the pgtk configuration, but I don't think I found
> any insight into my specific issue.
It seems to be a limitation of GTK+; it's not something we can solve,
unless the GTK developers finally decide to have most of the built-in
input modules stop removing the shift modifier when confronted with the
SPC key.
OTOH, if you're running X, I recommend you use the regular X port
instead. It will work much better in general, thanks to not having to
work around crazy limitations of GTK (child frame performance
immediately comes to mind.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52795
; Package
emacs
.
(Sun, 26 Dec 2021 14:27:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 52795 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>
>> On all of these, Emacs's "classical" X11+GTK configuration works fine;
>> other applications work fine too; the problems I describe only show up
>> in Emacs compiled --with-pgtk.
>
> WDYM by other applications? Are those GTK+ applications, and do they
> treat S-SCP differently from SPC?
Off the top of my head (testing on XFCE, because that's all I'll have
for the coming week):
- with Firefox, as in special-mode-map, SPC scrolls forward and S-SPC
scrolls backward,
- in Libreoffice Calc, SPC self-inserts, S-SPC selects the current row,
- XFCE's keyboard shortcut manager allows binding Shift-Space.
I don't know how much those rely on GTK+; possibly they do something
similar to Emacs's X11+GTK configuration?
> OTOH, if you're running X, I recommend you use the regular X port
> instead. It will work much better in general, thanks to not having to
> work around crazy limitations of GTK (child frame performance
> immediately comes to mind.)
Right; that was my uninformed conclusion so far. All my setups run X
for now, so I can keep running the X port, although I'm slightly miffed
by the fringe icons being so tiny on screens where I crank up DPI
scaling; afaict --with-pgtk handles this better.
I'm also idly curious about these GTK limitations; are they documented
somewhere (either Emacs-side or GTK-side)? When researching this S-SPC
issue, I tried to search for developer manuals and bug trackers, but the
only relevant results that showed up were Emacs related (that's how I
found out about the pgtk-use-im-context-on-new-connection /
pgtk-use-im-context knobs).
Thanks for your clarifications; setting aside my question on GTK
limitations, and my issue with fringe icons shrinking when increasing
DPI scaling (that would be… bug#37932, at first glance?), this can be
closed I guess?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52795
; Package
emacs
.
(Mon, 27 Dec 2021 00:47:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 52795 <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> Off the top of my head (testing on XFCE, because that's all I'll have
> for the coming week):
>
> - with Firefox, as in special-mode-map, SPC scrolls forward and S-SPC
> scrolls backward,
>
> - in Libreoffice Calc, SPC self-inserts, S-SPC selects the current row,
>
> - XFCE's keyboard shortcut manager allows binding Shift-Space.
>
> I don't know how much those rely on GTK+; possibly they do something
> similar to Emacs's X11+GTK configuration?
Yeah, all those programs use X directly to handle keyboard input.
> I'm also idly curious about these GTK limitations; are they documented
> somewhere (either Emacs-side or GTK-side)? When researching this S-SPC
> issue, I tried to search for developer manuals and bug trackers, but the
> only relevant results that showed up were Emacs related (that's how I
> found out about the pgtk-use-im-context-on-new-connection /
> pgtk-use-im-context knobs).
GTK people typically don't document what they think apps "shouldn't do",
which apparently includes treating S-SPC as distinct from SPC.
> Thanks for your clarifications; setting aside my question on GTK
> limitations, and my issue with fringe icons shrinking when increasing
> DPI scaling (that would be… bug#37932, at first glance?), this can be
> closed I guess?
I will look into the scaling (though I have no high-definition
monitor). I think that the bug report should remain open though, in
case some person wiser than I am has a solution.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52795
; Package
emacs
.
(Tue, 28 Dec 2021 08:32:02 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:
> I think that the bug report should remain open though, in
> case some person wiser than I am has a solution.
FWIW, I goofed around a bit in pgtkim.c:
[goof.patch (text/x-diff, attachment)]
[Message part 3 (text/plain, inline)]
AFAICT Emacs receives enough information to see S-SPC?
Hitting SPC and S-SPC 3 times each from emacs -Q (so without calling
(pgtk-use-im-context nil), and with dead keys fully functioning):
> space
> space
> space
> Shift_L
> S-space
> S-space
> S-space
No idea how easy it would be to pass on that information to the rest of
Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52795
; Package
emacs
.
(Tue, 28 Dec 2021 08:32:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52795
; Package
emacs
.
(Tue, 28 Dec 2021 09:40:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 52795 <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> AFAICT Emacs receives enough information to see S-SPC?
Yes, but after going through an input method module the S-SPC is lost.
> No idea how easy it would be to pass on that information to the rest
> of Emacs.
Not easy, if we want to keep input methods (which GTK uses to implement
the compose key) working.
This bug report was last modified 2 years and 334 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.