From: Alex Hutcheson via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 54027@debbugs.gnu.org
Subject: bug#54027: Wishlist: Support full CSI u specification for terminal input
Date: Sun, 27 Feb 2022 13:21:20 -0500 [thread overview]
Message-ID: <CACjgaUdj-3rsp1o4tj=9oTBHkQHJe7X9a7DUCy4EaXu6PicUXg@mail.gmail.com> (raw)
In-Reply-To: <83mtieoxpj.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3567 bytes --]
> I think just adding the missing combinations is a better way forward.
I think we're in agreement here, I was just suggesting how to add
the combinations to xterm.el without introducing a lot of boilerplate
code.
We basically need to support the cross-product of:
modifier combinations x ASCII characters
It seems like there are 7 possible modifier combinations:
- Control
- Meta
- Shift
- Control + Meta
- Control + Shift
- Meta + Shift
- Control + Shift + Meta
The code in the StackExchange post (https://emacs.stackexchange.com/a/13957
)
doesn't add support for "Meta + Shift" or plain "Shift", because those
combinations
generally already result in something that doesn't need any special
encoding
(e.g. a capital letter or symbol, possibly preceded by an ESC character if
Meta was
pressed). So we only *really* need to support the encodings for the
remaining 5.
At the same time, it might be reasonable to support the other 2, because
they're
still valid encodings, so a terminal might still end up sending them.
Then we have 95 ASCII characters to support: codes 32 through 126
(inclusive), which
covers all the ASCII alphanumeric and punctuation characters.
So our keymap will end up with 5 x 95 = 475 entries
(or 7 x 95 = 665 if we support Shift and Meta+Shift).
To add these entries to xterm.el, we could either:
1. Add 475 lines to xterm.el, with a hard-coded entry for each combination,
or
2. Add a nested loop of (modifier combinations x ASCII characters) that
generates those 475 entries at runtime when xterm.el is executed.
If we implement #2, it would actually allow us to reduce the lines of code
in xterm.el,
because we could delete the existing hard-coded entries.
On Sat, Feb 26, 2022 at 3:10 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Alex Hutcheson <alexhutcheson@google.com>
> > Date: Tue, 22 Feb 2022 20:07:40 -0500
> > Cc: 54027@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.
>
--
Alex Hutcheson
alexhutcheson@google.com
[-- Attachment #2: Type: text/html, Size: 5441 bytes --]
next prev parent reply other threads:[~2022-02-27 18:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-16 18:24 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
2022-02-17 23:14 ` Richard Stallman
2022-02-18 8:30 ` Eli Zaretskii
2022-02-23 1:07 ` Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-26 8:10 ` Eli Zaretskii
2022-02-27 18:21 ` Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-02-27 18:38 ` Eli Zaretskii
2022-02-27 18:53 ` Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-27 19:16 ` Eli Zaretskii
2022-02-28 3:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-28 12:17 ` Eli Zaretskii
2022-02-28 13:22 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-28 13:31 ` Eli Zaretskii
2022-02-28 15:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-25 1:25 ` Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-25 2:33 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACjgaUdj-3rsp1o4tj=9oTBHkQHJe7X9a7DUCy4EaXu6PicUXg@mail.gmail.com' \
--to=bug-gnu-emacs@gnu.org \
--cc=54027@debbugs.gnu.org \
--cc=alexhutcheson@google.com \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).