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

[Eli Zaretskii <eliz@gnu.org>]

> 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.