bug#54027: Wishlist: Support full CSI u specification for terminal input

bug#54027: Wishlist: Support full CSI u specification for terminal input

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

CSI u is a mechanism for reporting keystrokes that is more powerful than
the standard used in Unix.

The specification is detailed at:
http://www.leonerd.org.uk/hacks/fixterms/

The specification is implemented by iTerm2, which is a popular
GPL-licensed terminal for macOS:
https://iterm2.com/documentation-csiu.html

A variant of the specification is implemented by kitty, another
GPL-licensed terminal on Linux and macOS:
https://sw.kovidgoyal.net/kitty/keyboard-protocol/#comprehensive-keyboard-handling-in-terminals

The GPL-licensed mintty terminal for Windows also has support:
https://github.com/mintty/mintty/wiki/Keycodes

Emacs contains code in xterm.el that can handle a subset of the possible
key combinations encoded to this specification, but not all of them.
For example, iTerm2 is able to send an encoding for Ctrl-Shift-n (aka
C-N),
but Emacs is unable to recognized the CSI u encoding for this key
combination.

My feature request is to implement full support for the encoding, so
that users using a supported terminal can send the full range of
key combinations to an Emacs running in a terminal.

Additional context: https://emacs.stackexchange.com/a/13957

bug#54027: Wishlist: Support full CSI u specification for terminal input

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The specification is implemented by iTerm2, which is a popular
  > GPL-licensed terminal for macOS:
  > https://iterm2.com/documentation-csiu.html

We shouldn't spend time adding a feature to GNU Emacs
for the sake of running it on MacOS.

  > The GPL-licensed mintty terminal for Windows also has support:
  > https://github.com/mintty/mintty/wiki/Keycodes

Nor Windows.  We should not implement features that are of no use
on the GNU system.

  > A variant of the specification is implemented by kitty, another
  > GPL-licensed terminal on GNU/Linux and macOS:
  > https://sw.kovidgoyal.net/kitty/keyboard-protocol/#comprehensive-keyboard-handling-in-terminals

Since kitty runs on GNU/Linux, maybe it is worth implementing
this variant of the specification, for the sake of kitty.

It's a matter of weighing the work involved (development and
maintenance) against the benefits.

We could wait and see if this protocol catches on, on GNU/Linux.
If it does, it will surely be worthj supporting.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#54027: Wishlist: Support full CSI u specification for terminal input

[Eli Zaretskii]

> Resent-From: Alex Hutcheson <alexhutcheson@google.com>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs@gnu.org
> Resent-Sender: help-debbugs@gnu.org
> Date: Wed, 16 Feb 2022 18:24:13 +0000
> From:  Alex Hutcheson via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> CSI u is a mechanism for reporting keystrokes that is more powerful than
> the standard used in Unix.
> 
> The specification is detailed at:
> http://www.leonerd.org.uk/hacks/fixterms/
> 
> The specification is implemented by iTerm2, which is a popular
> GPL-licensed terminal for macOS:
> https://iterm2.com/documentation-csiu.html
> 
> A variant of the specification is implemented by kitty, another
> GPL-licensed terminal on Linux and macOS:
> https://sw.kovidgoyal.net/kitty/keyboard-protocol/#comprehensive-keyboard-handling-in-terminals
> 
> The GPL-licensed mintty terminal for Windows also has support:
> https://github.com/mintty/mintty/wiki/Keycodes
> 
> Emacs contains code in xterm.el that can handle a subset of the possible
> key combinations encoded to this specification, but not all of them.
> For example, iTerm2 is able to send an encoding for Ctrl-Shift-n (aka
> C-N),
> but Emacs is unable to recognized the CSI u encoding for this key
> combination.
> 
> My feature request is to implement full support for the encoding, so
> that users using a supported terminal can send the full range of
> key combinations to an Emacs running in a terminal.
> 
> Additional context: https://emacs.stackexchange.com/a/13957

The SE article says that Emacs already supports the xterm's variant of
the solution to this problem, but not all the sequences are yet in
xterm.el.  So I think a simpler way forward would be to add the
missing sequences to xterm.el.

kitty is a problematic terminal emulator, from the POV of an Emacs
user; see etc/PROBLEMS for the details.  Given its behavior and the
staunch resistance of the developer to make any changes in it, I think
we should discourage Emacs users from using kitty.

bug#54027: Wishlist: Support full CSI u specification for terminal input

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

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

> kitty is a problematic terminal emulator, from the POV of an Emacs

Thanks for the context - I wasn't aware. We can forget about kitty then.

I've done a bit more research and realized that xterm also supports this
encoding. It just requires the formatOtherKeys setting to be enabled.

A couple links I found useful:

- A detailed overview of the issue from the maintainer of xterm.
  This covers both the original "CSI 27" encoding and the newer
  "CSI u" encoding: https://invisible-island.net/xterm/modified-keys.html
- A much briefer summary:
https://github.com/microsoft/terminal/issues/8719#issuecomment-826528702
- The xterm man page (see "formatOtherKeys"):
https://invisible-island.net/xterm/manpage/xterm.html

I also realized that this has actually been discussed in the past,
and Emacs actually added support for many CSI u sequences to
 xterm.el: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13839

I think the only remaining work is to extend that support to cover
all reasonable combinations of modifiers and keys, which is what
the code snippet in the StackExchange answer attempts to do.

We're currently hard-coding the possible combinations of
modifiers and keys that we support:
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/term/xterm.el#n464
An alternative approach would be to replace that hard-coded list
with a programatically-generated list that includes every combination
of modifiers and keys.

[-- Attachment #2: Type: text/html, Size: 2443 bytes --]

bug#54027: Wishlist: Support full CSI u specification for terminal input

[Eli Zaretskii]

> From: Alex Hutcheson <alexhutcheson@google.com>
> Date: Tue, 22 Feb 2022 20:07:40 -0500
> Cc: 54027@debbugs.gnu.org
> 
> - A detailed overview of the issue from the maintainer of xterm. 
>   This covers both the original "CSI 27" encoding and the newer
>   "CSI u" encoding: https://invisible-island.net/xterm/modified-keys.html
> - A much briefer summary: https://github.com/microsoft/terminal/issues/8719#issuecomment-826528702
> - The xterm man page (see "formatOtherKeys"): https://invisible-island.net/xterm/manpage/xterm.html
> 
> I also realized that this has actually been discussed in the past,
> and Emacs actually added support for many CSI u sequences to
>  xterm.el: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13839
> 
> I think the only remaining work is to extend that support to cover
> all reasonable combinations of modifiers and keys, which is what
> the code snippet in the StackExchange answer attempts to do.

Right, but I'd rather the additional keys followed the same format as
in the above-mentioned patch by Stefan, posted in bug#13839, because
that is what we have in xterm.el nowadays.

> We're currently hard-coding the possible combinations of 
> modifiers and keys that we support:
> https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/term/xterm.el#n464
> An alternative approach would be to replace that hard-coded list
> with a programatically-generated list that includes every combination 
> of modifiers and keys.

I'm not sure I understand how you can programmatically generate a list
of keys: wouldn't it still involve a manually-maintained list at some
level?

I think just adding the missing combinations is a better way forward.

Thanks.

bug#54027: Wishlist: Support full CSI u specification for terminal input

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

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

> I think just adding the missing combinations is a better way forward.

I think we're in agreement here, I was just suggesting how to add
the combinations to xterm.el without introducing a lot of boilerplate
code.

We basically need to support the cross-product of:
modifier combinations x ASCII characters

It seems like there are 7 possible modifier combinations:
- Control
- Meta
- Shift
- Control + Meta
- Control + Shift
- Meta + Shift
- Control + Shift + Meta

The code in the StackExchange post (https://emacs.stackexchange.com/a/13957
)
doesn't add support for "Meta + Shift" or plain "Shift", because those
combinations
generally already result in something that doesn't need any special
encoding
(e.g. a capital letter or symbol, possibly preceded by an ESC character if
Meta was
pressed). So we only *really* need to support the encodings for the
remaining 5.
At the same time, it might be reasonable to support the other 2, because
they're
still valid encodings, so a terminal might still end up sending them.

Then we have 95 ASCII characters to support: codes 32 through 126
(inclusive), which
covers all the ASCII alphanumeric and punctuation characters.

So our keymap will end up with 5 x 95 = 475 entries
(or 7 x 95 = 665 if we support Shift and Meta+Shift).

To add these entries to xterm.el, we could either:
1. Add 475 lines to xterm.el, with a hard-coded entry for each combination,
or
2. Add a nested loop of (modifier combinations x ASCII characters) that
  generates those 475 entries at runtime when xterm.el is executed.

If we implement #2, it would actually allow us to reduce the lines of code
in xterm.el,
because we could delete the existing hard-coded entries.

On Sat, Feb 26, 2022 at 3:10 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Alex Hutcheson <alexhutcheson@google.com>
> > Date: Tue, 22 Feb 2022 20:07:40 -0500
> > Cc: 54027@debbugs.gnu.org
> >
> > - A detailed overview of the issue from the maintainer of xterm.
> >   This covers both the original "CSI 27" encoding and the newer
> >   "CSI u" encoding:
> https://invisible-island.net/xterm/modified-keys.html
> > - A much briefer summary:
> https://github.com/microsoft/terminal/issues/8719#issuecomment-826528702
> > - The xterm man page (see "formatOtherKeys"):
> https://invisible-island.net/xterm/manpage/xterm.html
> >
> > I also realized that this has actually been discussed in the past,
> > and Emacs actually added support for many CSI u sequences to
> >  xterm.el: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13839
> >
> > I think the only remaining work is to extend that support to cover
> > all reasonable combinations of modifiers and keys, which is what
> > the code snippet in the StackExchange answer attempts to do.
>
> Right, but I'd rather the additional keys followed the same format as
> in the above-mentioned patch by Stefan, posted in bug#13839, because
> that is what we have in xterm.el nowadays.
>
> > We're currently hard-coding the possible combinations of
> > modifiers and keys that we support:
> > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/term/xterm.el#n464
> > An alternative approach would be to replace that hard-coded list
> > with a programatically-generated list that includes every combination
> > of modifiers and keys.
>
> I'm not sure I understand how you can programmatically generate a list
> of keys: wouldn't it still involve a manually-maintained list at some
> level?
>
> I think just adding the missing combinations is a better way forward.
>
> Thanks.
>


-- 
Alex Hutcheson
alexhutcheson@google.com

[-- Attachment #2: Type: text/html, Size: 5441 bytes --]

bug#54027: Wishlist: Support full CSI u specification for terminal input

[Eli Zaretskii]

> From: Alex Hutcheson <alexhutcheson@google.com>
> Date: Sun, 27 Feb 2022 13:21:20 -0500
> Cc: 54027@debbugs.gnu.org
> 
> We basically need to support the cross-product of:
> modifier combinations x ASCII characters

No, AFAIU we only need to support keys+modifiers that are not
otherwise supported already.  E.g., C-a is already supported, so we
don't need to add it, and similarly many other combinations are
already supported.  Or what am I missing?

bug#54027: Wishlist: Support full CSI u specification for terminal input

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

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

My thinking is that it's very low-cost to support all possible encodings,
even if it's unlikely that a terminal would actually send them.

Using your example:
\e[65;5u
Would be a valid way to encode C-a according to the spec at
http://www.leonerd.org.uk/hacks/fixterms/

Most terminals will not encode it that way, and will instead send ^A,
but it would be nice to support it gracefully if a terminal happens to
send C-a encoded that way.

In addition, the "just support all inputs encoded this way" approach
seems simpler to understand and maintain than an approach that
distinguishes between key combinations that have an existing
alternative encoding and those that don't.
The entries in the keymap won't be referenced unless Emacs actually
receives matching input, so the cost of having entries for additional
combinations seems fairly minimal.

Maybe I'm misunderstanding keymap performance or some other
important parameter, though?

On Sun, Feb 27, 2022 at 1:38 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Alex Hutcheson <alexhutcheson@google.com>
> > Date: Sun, 27 Feb 2022 13:21:20 -0500
> > Cc: 54027@debbugs.gnu.org
> >
> > We basically need to support the cross-product of:
> > modifier combinations x ASCII characters
>
> No, AFAIU we only need to support keys+modifiers that are not
> otherwise supported already.  E.g., C-a is already supported, so we
> don't need to add it, and similarly many other combinations are
> already supported.  Or what am I missing?
>


-- 
Alex Hutcheson
alexhutcheson@google.com

[-- Attachment #2: Type: text/html, Size: 2482 bytes --]

bug#54027: Wishlist: Support full CSI u specification for terminal input

[Eli Zaretskii]

> From: Alex Hutcheson <alexhutcheson@google.com>
> Date: Sun, 27 Feb 2022 13:53:56 -0500
> Cc: 54027@debbugs.gnu.org
> 
> My thinking is that it's very low-cost to support all possible encodings, 
> even if it's unlikely that a terminal would actually send them.
> 
> Using your example:
> \e[65;5u
> Would be a valid way to encode C-a according to the spec at 
> http://www.leonerd.org.uk/hacks/fixterms/
> 
> Most terminals will not encode it that way, and will instead send ^A, 
> but it would be nice to support it gracefully if a terminal happens to 
> send C-a encoded that way.
> 
> In addition, the "just support all inputs encoded this way" approach
> seems simpler to understand and maintain than an approach that
> distinguishes between key combinations that have an existing 
> alternative encoding and those that don't.
> The entries in the keymap won't be referenced unless Emacs actually
> receives matching input, so the cost of having entries for additional
> combinations seems fairly minimal.
> 
> Maybe I'm misunderstanding keymap performance or some other
> important parameter, though?

Let's add Stefan to this discussion.

Stefan, any comments or thoughts?

> 
> On Sun, Feb 27, 2022 at 1:38 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  > From: Alex Hutcheson <alexhutcheson@google.com>
>  > Date: Sun, 27 Feb 2022 13:21:20 -0500
>  > Cc: 54027@debbugs.gnu.org
>  > 
>  > We basically need to support the cross-product of:
>  > modifier combinations x ASCII characters
> 
>  No, AFAIU we only need to support keys+modifiers that are not
>  otherwise supported already.  E.g., C-a is already supported, so we
>  don't need to add it, and similarly many other combinations are
>  already supported.  Or what am I missing?
> 
> -- 
> Alex Hutcheson
> alexhutcheson@google.com

bug#54027: Wishlist: Support full CSI u specification for terminal input

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

Alex Hutcheson [2022-02-27 13:21:20] wrote:
>> I think just adding the missing combinations is a better way forward.
> I think we're in agreement here, I was just suggesting how to add
> the combinations to xterm.el without introducing a lot of boilerplate
> code.

Actually, for `ESC [ 27 ...` the better option is to bind `ESC [ 27` to
a function that reads the subsequent parameters so it will handle *all*
cases in one go, as in the barely tested patch below.

For `ESC [ ... u` it's a bit more tricky because it doesn't have such
a "clean" prefix (it's distinguished by the final `u` instead), so we'd
have to rework a lot of the rest of the `ESC [` bindings.
Maybe not a bad idea, tho.


        Stefan


diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index a7e257f41c5..9bf6a5750b1 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -192,6 +192,41 @@ xterm-rxvt-function-map
     map)
   "Keymap of escape sequences, shared between xterm and rxvt support.")
 
+(defun xterm--read-csi ()
+  ;; Format described in the "Control Sequence Introducer" section:
+  ;; https://en.wikipedia.org/wiki/ANSI_escape_code#CSIsection.
+  (let ((params '())
+        (intermediates '())
+        (final nil))
+    (setq final (read-char))
+    (while (<= #x30 final #x3F)
+      (push final params) ;And read more.
+      (setq final (read-char)))
+    (while (<= #x20 final #x2F)
+      (push final intermediates)
+      (setq final (read-char)))
+    (list (nreverse params) (nreverse intermediates) final)))
+
+(defun xterm--csi-27-modified-keys (&rest _)
+  (pcase-let* ((csi (xterm--read-csi))
+               (`(,params ,intermediates ,final) csi)
+               (tmp nil))
+    (cond
+     ((and (eq final ?~) (null intermediates)
+           (setq tmp (apply #'string params))
+           (string-match "\\([1-9][0-9]*\\);\\([0-9]+\\)" tmp))
+      (let ((modifiers (1- (string-to-number (match-string 1 tmp))))
+            (char (string-to-number (match-string 2 tmp))))
+        (vector
+         (+ char
+            (if (zerop (logand modifiers 1)) 0 ?\S-\0)
+            (if (zerop (logand modifiers 2)) 0 ?\A-\0)
+            (if (zerop (logand modifiers 4)) 0 ?\C-\0)
+            (if (zerop (logand modifiers 8)) 0 ?\M-\0)))))
+     (t
+      (message "Unknown CSI-27 sequence: %S" csi)
+      []))))
+
 (defvar xterm-function-map
   (let ((map (make-sparse-keymap)))
     (set-keymap-parent map xterm-rxvt-function-map)
@@ -576,12 +611,12 @@ xterm-function-map
 
                     (6 9   [C-S-tab])
                     (6 13  [C-S-return])))
-      (define-key map
-        (format "\e[27;%d;%d~" (nth 0 bind) (nth 1 bind)) (nth 2 bind))
       ;; For formatOtherKeys=1, the sequence is a bit shorter (bug#13839).
       (define-key map
         (format "\e[%d;%du" (nth 1 bind) (nth 0 bind)) (nth 2 bind)))
 
+    (define-key map "\e[27;" #'xterm--csi-27-modified-keys)
+
     ;; Other versions of xterm might emit these.
     (define-key map "\e[1~" [home])
 

bug#54027: Wishlist: Support full CSI u specification for terminal input

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  54027@debbugs.gnu.org
> Date: Sun, 27 Feb 2022 22:49:58 -0500
> 
> Alex Hutcheson [2022-02-27 13:21:20] wrote:
> >> I think just adding the missing combinations is a better way forward.
> > I think we're in agreement here, I was just suggesting how to add
> > the combinations to xterm.el without introducing a lot of boilerplate
> > code.
> 
> Actually, for `ESC [ 27 ...` the better option is to bind `ESC [ 27` to
> a function that reads the subsequent parameters so it will handle *all*
> cases in one go, as in the barely tested patch below.
> 
> For `ESC [ ... u` it's a bit more tricky because it doesn't have such
> a "clean" prefix (it's distinguished by the final `u` instead), so we'd
> have to rework a lot of the rest of the `ESC [` bindings.
> Maybe not a bad idea, tho.

Thanks, but what is your opinion about which of the combinations we
need to add?

bug#54027: Wishlist: Support full CSI u specification for terminal input

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

Eli Zaretskii [2022-02-28 14:17:45] wrote:
>> Alex Hutcheson [2022-02-27 13:21:20] wrote:
>> >> I think just adding the missing combinations is a better way forward.
>> > I think we're in agreement here, I was just suggesting how to add
>> > the combinations to xterm.el without introducing a lot of boilerplate
>> > code.
>> 
>> Actually, for `ESC [ 27 ...` the better option is to bind `ESC [ 27` to
>> a function that reads the subsequent parameters so it will handle *all*
>> cases in one go, as in the barely tested patch below.
>> 
>> For `ESC [ ... u` it's a bit more tricky because it doesn't have such
>> a "clean" prefix (it's distinguished by the final `u` instead), so we'd
>> have to rework a lot of the rest of the `ESC [` bindings.
>> Maybe not a bad idea, tho.
>
> Thanks, but what is your opinion about which of the combinations we
> need to add?

The patch I posted adds all of them, and that reflects my opinion (tho
the patch only bothered to do it for the `ESC [ 27 ...` format).


        Stefan

bug#54027: Wishlist: Support full CSI u specification for terminal input

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: alexhutcheson@google.com,  54027@debbugs.gnu.org
> Date: Mon, 28 Feb 2022 08:22:05 -0500
> 
> > Thanks, but what is your opinion about which of the combinations we
> > need to add?
> 
> The patch I posted adds all of them, and that reflects my opinion (tho
> the patch only bothered to do it for the `ESC [ 27 ...` format).

Then I must be missing something.  Do you mean this part:

  +    (while (<= #x30 final #x3F)
  +      (push final params) ;And read more.
  +      (setq final (read-char)))
  +    (while (<= #x20 final #x2F)
  +      (push final intermediates)
  +      (setq final (read-char)))

This doesn't add all the 96 characters with the modifiers, it only
adds the digits and the punctuation characters.

bug#54027: Wishlist: Support full CSI u specification for terminal input

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

> Then I must be missing something.  Do you mean this part:
>
>   +    (while (<= #x30 final #x3F)
>   +      (push final params) ;And read more.
>   +      (setq final (read-char)))
>   +    (while (<= #x20 final #x2F)
>   +      (push final intermediates)
>   +      (setq final (read-char)))
>
> This doesn't add all the 96 characters with the modifiers, it only
> adds the digits and the punctuation characters.

The above just reads to "NN;MM" part of the escape sequence which
encodes in decimal the Unicode code point MM of the character and the
4bit encoded NN of the modifiers shift, alt, control, and meta.


        Stefan

bug#54027: Wishlist: Support full CSI u specification for terminal input

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

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

Was a consensus ever reached on this?

Stefan's patch looks like it does what I was asking for.

It would be great if we could also handle the `ESC [ ... u` versions,
because xterm will emit them in
some configurations, and iTerm2 can only emit those.

On Mon, Feb 28, 2022 at 10:25 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > Then I must be missing something.  Do you mean this part:
> >
> >   +    (while (<= #x30 final #x3F)
> >   +      (push final params) ;And read more.
> >   +      (setq final (read-char)))
> >   +    (while (<= #x20 final #x2F)
> >   +      (push final intermediates)
> >   +      (setq final (read-char)))
> >
> > This doesn't add all the 96 characters with the modifiers, it only
> > adds the digits and the punctuation characters.
>
> The above just reads to "NN;MM" part of the escape sequence which
> encodes in decimal the Unicode code point MM of the character and the
> 4bit encoded NN of the modifiers shift, alt, control, and meta.
>
>
>         Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 1505 bytes --]

bug#54027: Wishlist: Support full CSI u specification for terminal input

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

Alex Hutcheson [2022-05-24 21:25:03] wrote:
> Was a consensus ever reached on this?
> Stefan's patch looks like it does what I was asking for.

I didn't install my patch because IIUC it interferes with some other
bindings (it takes over a particular ESC prefix which some other
package also needs to use).  IOW it needs to be improved so that it can
cooperate with other users of such key sequences.
IIRC `xt-mouse.el` is affected, for example.


        Stefan