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" <bug-gnu-emacs@gnu.org>]

[-- 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 --]