> 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
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.