GNU bug report logs -
#54027
Wishlist: Support full CSI u specification for terminal input
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 <at> gnu.org> wrote:
> > From: Alex Hutcheson <alexhutcheson <at> google.com>
> > Date: Sun, 27 Feb 2022 13:21:20 -0500
> > Cc: 54027 <at> 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 <at> google.com
[Message part 2 (text/html, inline)]
This bug report was last modified 3 years and 54 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.