* bug#52795: 29.0.50; pgtk: issues with key bindings
@ 2021-12-25 18:00 Kévin Le Gouguec
2021-12-26 1:33 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 6+ messages in thread
From: Kévin Le Gouguec @ 2021-12-25 18:00 UTC (permalink / raw)
To: 52795
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#52795: 29.0.50; pgtk: issues with key bindings
2021-12-25 18:00 bug#52795: 29.0.50; pgtk: issues with key bindings Kévin Le Gouguec
@ 2021-12-26 1:33 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-26 14:25 ` Kévin Le Gouguec
0 siblings, 1 reply; 6+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-26 1:33 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: 52795
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.)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#52795: 29.0.50; pgtk: issues with key bindings
2021-12-26 1:33 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-12-26 14:25 ` Kévin Le Gouguec
2021-12-27 0:46 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 6+ messages in thread
From: Kévin Le Gouguec @ 2021-12-26 14:25 UTC (permalink / raw)
To: Po Lu; +Cc: 52795
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#52795: 29.0.50; pgtk: issues with key bindings
2021-12-26 14:25 ` Kévin Le Gouguec
@ 2021-12-27 0:46 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-28 8:31 ` Kévin Le Gouguec
0 siblings, 1 reply; 6+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-27 0:46 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: 52795
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#52795: 29.0.50; pgtk: issues with key bindings
2021-12-27 0:46 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-12-28 8:31 ` Kévin Le Gouguec
2021-12-28 9:39 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 6+ messages in thread
From: Kévin Le Gouguec @ 2021-12-28 8:31 UTC (permalink / raw)
To: 52795; +Cc: luangruo
[-- 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.
^ permalink raw reply related [flat|nested] 6+ messages in thread
* bug#52795: 29.0.50; pgtk: issues with key bindings
2021-12-28 8:31 ` Kévin Le Gouguec
@ 2021-12-28 9:39 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 6+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-28 9:39 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: 52795
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-12-28 9:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-25 18:00 bug#52795: 29.0.50; pgtk: issues with key bindings Kévin Le Gouguec
2021-12-26 1:33 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-26 14:25 ` Kévin Le Gouguec
2021-12-27 0:46 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-28 8:31 ` Kévin Le Gouguec
2021-12-28 9:39 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.