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: 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: Fri, 18 Feb 2022 10:30:18 +0200

> Resent-From: Alex Hutcheson <alexhutcheson <at> google.com>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs <at> gnu.org
> Resent-Sender: help-debbugs <at> gnu.org
> Date: Wed, 16 Feb 2022 18:24:13 +0000
> From:  Alex Hutcheson via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> CSI u is a mechanism for reporting keystrokes that is more powerful than
> the standard used in Unix.
> 
> The specification is detailed at:
> http://www.leonerd.org.uk/hacks/fixterms/
> 
> The specification is implemented by iTerm2, which is a popular
> GPL-licensed terminal for macOS:
> https://iterm2.com/documentation-csiu.html
> 
> A variant of the specification is implemented by kitty, another
> GPL-licensed terminal on Linux and macOS:
> https://sw.kovidgoyal.net/kitty/keyboard-protocol/#comprehensive-keyboard-handling-in-terminals
> 
> The GPL-licensed mintty terminal for Windows also has support:
> https://github.com/mintty/mintty/wiki/Keycodes
> 
> Emacs contains code in xterm.el that can handle a subset of the possible
> key combinations encoded to this specification, but not all of them.
> For example, iTerm2 is able to send an encoding for Ctrl-Shift-n (aka
> C-N),
> but Emacs is unable to recognized the CSI u encoding for this key
> combination.
> 
> My feature request is to implement full support for the encoding, so
> that users using a supported terminal can send the full range of
> key combinations to an Emacs running in a terminal.
> 
> Additional context: https://emacs.stackexchange.com/a/13957

The SE article says that Emacs already supports the xterm's variant of
the solution to this problem, but not all the sequences are yet in
xterm.el.  So I think a simpler way forward would be to add the
missing sequences to xterm.el.

kitty is a problematic terminal emulator, from the POV of an Emacs
user; see etc/PROBLEMS for the details.  Given its behavior and the
staunch resistance of the developer to make any changes in it, I think
we should discourage Emacs users from using kitty.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.