bug#60077: closed (29.0.60; Is xterm modifyOtherKeys support broken?)

[GNU bug Tracking System]

Your message dated Fri, 16 Dec 2022 18:04:09 +0200
with message-id <835yebjpxi.fsf@gnu.org>
and subject line Re: bug#60077: 29.0.60; Is xterm modifyOtherKeys support 
broken?
has caused the debbugs.gnu.org bug report #60077,
regarding 29.0.60; Is xterm modifyOtherKeys support broken?
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
60077: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60077
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: 29.0.60; Is xterm modifyOtherKeys support broken? Date: Thu, 15 Dec 2022 10:48:35 +1300

I often run emacs in the terminal, and usually this is inside wezterm as my
terminal emulator. Recently wezterm has added support for the
modifyOtherKeys xterm extension, and since then emacs M-SPC has stopped
working in the terminal (instead it inserts "~32").

I can get M-SPC working again in wezterm by preventing emacs from enabling
modifyOtherKeys, either by setting xterm-extra-capabilities to nil or by
stubbing out xterm--init-modify-other-keys. Initially we thought that
this may be a problem with wezterm, but then I tried replicating with
xterm and exactly the same thing happens. This suggests to me that the
issue is with emacs rather than xterm or wezterm.

To replicate:

1) run: xterm -e emacs -nw -Q
2) in say *scratch* check whether M-SPC works or whether it inserts ~32
(for me it inserts ~32)

To replicate disabling modifyOtherKeys:

1) put the following into $HOME/test-dir/init.el
------
;; Dirty hack to not use xterm modifyOtherKeys feature
(defun my-disable-xterm--init-modify-other-keys (orig-fun &rest args))
(advice-add #'xterm--init-modify-other-keys :around
            #'my-disable-xterm--init-modify-other-keys)
------
2) run: xterm -e emacs -nw --init-dir=$HOME/test-dir
3) in say *scratch* check whether M-SPC works or whether it inserts ~32
(for me it works correctly)

This seems to demonstrate the out of the box behaviour being broken, but
I don't understand enough about terminals etc to know whether there is
some other factor at play.

Relevant link where this was discussed:
https://github.com/CyberShadow/term-keys/issues/14

Cheers,

Len.

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#60077: 29.0.60; Is xterm modifyOtherKeys support broken?
>
>
>
>
> Date: 
>
> Fri, 16 Dec 2022 18:04:09 +0200
>
>
>
>
> > Cc: dann@ics.uci.edu, 60077@debbugs.gnu.org
> > Date: Fri, 16 Dec 2022 08:52:30 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > From: Len Trigg <lenbok@gmail.com>
> > > Date: Fri, 16 Dec 2022 08:48:54 +1300
> > > Cc: 60077@debbugs.gnu.org, dann@ics.uci.edu
> > > 
> > > On Thu, 15 Dec 2022 at 22:10, Eli Zaretskii <eliz@gnu.org> wrote:
> > > 
> > >  > And my wild speculation from looking at the example table "Other 
> > > modified-key escapes" on
> > >  > https://invisible-island.net/xterm/modified-keys-us-pc105.html is that 
> > > emacs would need an entry like:
> > >  >                    (3 32 [?\M-\s])
> > >  > to handle the modifyOtherKeys encoding of "\E[27;3;32~" for M-SPC,
> > > 
> > >  If that fixes the problem, we could install it.
> > > 
> > > I tried this out and it does fix the issue for me.
> > 
> > OK, will install that soon.
>
> Now done on the emacs-29 branch, and closing the bug.
>
> Thanks.
>
>
> --- End Message ---