GNU bug report logs - #54027
Wishlist: Support full CSI u specification for terminal input

Previous Next

Package: emacs;

Reported by: Alex Hutcheson <alexhutcheson <at> google.com>

Date: Wed, 16 Feb 2022 18:25:02 UTC

Severity: wishlist

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex Hutcheson <alexhutcheson <at> google.com>
Cc: 54027 <at> debbugs.gnu.org
Subject: bug#54027: Wishlist: Support full CSI u specification for terminal input
Date: Sat, 26 Feb 2022 10:10:00 +0200
> 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.