> 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