GNU bug report logs -
#54027
Wishlist: Support full CSI u specification for terminal input
Previous Next
Full log
View this message in rfc822 format
> From: Alex Hutcheson <alexhutcheson <at> google.com>
> Date: Tue, 22 Feb 2022 20:07:40 -0500
> Cc: 54027 <at> 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.
This bug report was last modified 3 years and 26 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.