bug#55660: 29.0.50; PGTK degrades to terminal-compatible keyboard events

bug#55660: 29.0.50; PGTK degrades to terminal-compatible keyboard events

[Derek Upham]

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

bug#55660: 29.0.50; PGTK degrades to terminal-compatible keyboard events

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

Derek Upham <derek_upham@mailfence.com> writes:

> 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

What happens if you turn off input method support, by evaluating
(pgtk-use-im-context nil)?  In general, these problems are not with
Emacs, but with GTK input method modules, and should be reported to
their developers instead.

Emacs never "degrades" to "terminal-compatible" input events when using
a window system.  We directly use whatever it reports.

bug#55660: 29.0.50; PGTK degrades to terminal-compatible keyboard events

[Derek Upham]

Po Lu <luangruo@yahoo.com> writes:

> What happens if you turn off input method support, by evaluating
> (pgtk-use-im-context nil)?  In general, these problems are not 
> with
> Emacs, but with GTK input method modules, and should be reported 
> to
> their developers instead.
>
> Emacs never "degrades" to "terminal-compatible" input events 
> when using
> a window system.  We directly use whatever it reports.

Calling that function restores normal rich events.

I’m using Ubuntu 20.04.  The distro installs ibus-gtk3 as part of 
the normal desktop experience, but I haven’t configured it. 
“im-config” reports that it’s using the default en_US locale.

bug#55660: 29.0.50; PGTK degrades to terminal-compatible keyboard events

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

Derek Upham <derek_upham@mailfence.com> writes:

> Calling that function restores normal rich events.
>
> I’m using Ubuntu 20.04.  The distro installs ibus-gtk3 as part of the
> normal desktop experience, but I haven’t configured it. “im-config”
> reports that it’s using the default en_US locale.

Then this is a duplicate of bug#53200 (and many other similar issues).
Would someone please merge the two?

bug#55660: 29.0.50; PGTK degrades to terminal-compatible keyboard events

[Eli Zaretskii]

merge 55660 53200
thanks

> Cc: 55660@debbugs.gnu.org
> Date: Fri, 27 May 2022 09:59:43 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Derek Upham <derek_upham@mailfence.com> writes:
> 
> > Calling that function restores normal rich events.
> >
> > I’m using Ubuntu 20.04.  The distro installs ibus-gtk3 as part of the
> > normal desktop experience, but I haven’t configured it. “im-config”
> > reports that it’s using the default en_US locale.
> 
> Then this is a duplicate of bug#53200 (and many other similar issues).
> Would someone please merge the two?

Done (and anyone can easily do that).

Should this issue be in PROBLEMS?

bug#55660: 29.0.50; PGTK degrades to terminal-compatible keyboard events

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

Eli Zaretskii <eliz@gnu.org> writes:

> Done (and anyone can easily do that).

Thanks for showing the procedure.

> Should this issue be in PROBLEMS?

I guess so, I will probably write an entry in a while.

bug#55660: 29.0.50; PGTK degrades to terminal-compatible keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: derek_upham@mailfence.com,  55660@debbugs.gnu.org
> Date: Fri, 27 May 2022 14:06:34 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Should this issue be in PROBLEMS?
> 
> I guess so, I will probably write an entry in a while.

Thanks, but shouldn't the heading line of the entry you added be
qualified with "in PGTK builds"? or maybe "in GTK and PGTK builds"?

bug#55660: 29.0.50; PGTK degrades to terminal-compatible keyboard events

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

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, but shouldn't the heading line of the entry you added be
> qualified with "in PGTK builds"? or maybe "in GTK and PGTK builds"?

It's already under "Runtime problems specific to PGTK".

bug#55660: 29.0.50; PGTK degrades to terminal-compatible keyboard events

[Derek Upham]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Thanks, but shouldn't the heading line of the entry you added 
>> be
>> qualified with "in PGTK builds"? or maybe "in GTK and PGTK 
>> builds"?
>
> It's already under "Runtime problems specific to PGTK".

How about this?

** Keyboard behavior depends on your GTK input method

The GTK3 libraries may interpret and process keypresses as part of 
the
current GTK input method, before passing them as input events to 
Emacs.
GTK applications like PGTK Emacs configure their input method
automatically based on environment variables, particularly LANG 
and
GTK_IM_MODULE.

If you notice differences in keyboard behavior depending on how 
you
start PGTK Emacs, compare your environments using 
`process-environment'.
For example, you may see behavior differences when running Emacs 
out of
a systemd unit file, compared to running Emacs from the command 
line.
Input methods may also cause the keyboard behavior to change if 
you
switch from a GTK-based build to a PGTK-based build.

Emacs may reveal bugs that are in the input method libraries. 
Those
libraries are out of Emacs's control, but you can tell PGTK Emacs 
to
bypass input methods entirely using an Emacs Lisp function:

  M-: (pgtk-use-im-context nil)

bug#55660: 29.0.50; PGTK degrades to terminal-compatible keyboard events

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

Derek Upham <derek_upham@mailfence.com> writes:

> How about this?
>
> ** Keyboard behavior depends on your GTK input method
>
> The GTK3 libraries may interpret and process keypresses as part of the
> current GTK input method, before passing them as input events to
> Emacs.
> GTK applications like PGTK Emacs configure their input method
> automatically based on environment variables, particularly LANG and
> GTK_IM_MODULE.
>
> If you notice differences in keyboard behavior depending on how you
> start PGTK Emacs, compare your environments using
> `process-environment'.
> For example, you may see behavior differences when running Emacs out
> of
> a systemd unit file, compared to running Emacs from the command line.
> Input methods may also cause the keyboard behavior to change if you
> switch from a GTK-based build to a PGTK-based build.
>
> Emacs may reveal bugs that are in the input method libraries. Those
> libraries are out of Emacs's control, but you can tell PGTK Emacs to
> bypass input methods entirely using an Emacs Lisp function:
>
>  M-: (pgtk-use-im-context nil)

No, that doesn't describe the problem very well.  `process-environment'
is certainly completely unrelated, and the description is much more
vague, with no examples of what can go wrong with faulty input methods.

The first half of the entry also describes a different problem, which
has already been in PROBLEMS for a while.