bug#52795: 29.0.50; pgtk: issues with key bindings

bug#52795: 29.0.50; pgtk: issues with key bindings

[Kévin Le Gouguec]

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

bug#52795: 29.0.50; pgtk: issues with key bindings

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

Kévin Le Gouguec <kevin.legouguec@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.)

bug#52795: 29.0.50; pgtk: issues with key bindings

[Kévin Le Gouguec]

Po Lu <luangruo@yahoo.com> writes:

> Kévin Le Gouguec <kevin.legouguec@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?

bug#52795: 29.0.50; pgtk: issues with key bindings

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

Kévin Le Gouguec <kevin.legouguec@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.

bug#52795: 29.0.50; pgtk: issues with key bindings

[Kévin Le Gouguec]

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

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: goof.patch --]
[-- Type: text/x-diff, Size: 929 bytes --]

diff --git a/src/pgtkim.c b/src/pgtkim.c
index c0104ebc0a..6e4c763b08 100644
--- a/src/pgtkim.c
+++ b/src/pgtkim.c
@@ -18,6 +18,8 @@ Copyright (C) 1989, 1993-1994, 2005-2006, 2008-2020 Free Software
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 
+#include <stdio.h>
+
 /* This should be the first include, as it may set up #defines affecting
    interpretation of even the system includes. */
 #include <config.h>
@@ -201,6 +203,12 @@ pgtk_im_focus_out (struct frame *f)
 bool
 pgtk_im_filter_keypress (struct frame *f, GdkEventKey * ev)
 {
+  if (ev->state & GDK_SHIFT_MASK)
+    fprintf(stderr, "S-");
+  if (ev->state & GDK_CONTROL_MASK)
+    fprintf(stderr, "C-");
+  fprintf(stderr, "%s\n", gdk_keyval_name(ev->keyval));
+
   struct pgtk_display_info *dpyinfo = FRAME_DISPLAY_INFO (f);
   if (dpyinfo->im.context != NULL)
     {

[-- Attachment #3: Type: text/plain, Size: 337 bytes --]


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.

bug#52795: 29.0.50; pgtk: issues with key bindings

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

Kévin Le Gouguec <kevin.legouguec@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.