My thinking is that it's very low-cost to support all possible encodings, even if it's unlikely that a terminal would actually send them. Using your example: \e[65;5u Would be a valid way to encode C-a according to the spec at http://www.leonerd.org.uk/hacks/fixterms/ Most terminals will not encode it that way, and will instead send ^A, but it would be nice to support it gracefully if a terminal happens to send C-a encoded that way. In addition, the "just support all inputs encoded this way" approach seems simpler to understand and maintain than an approach that distinguishes between key combinations that have an existing alternative encoding and those that don't. The entries in the keymap won't be referenced unless Emacs actually receives matching input, so the cost of having entries for additional combinations seems fairly minimal. Maybe I'm misunderstanding keymap performance or some other important parameter, though? On Sun, Feb 27, 2022 at 1:38 PM Eli Zaretskii wrote: > > From: Alex Hutcheson > > Date: Sun, 27 Feb 2022 13:21:20 -0500 > > Cc: 54027@debbugs.gnu.org > > > > We basically need to support the cross-product of: > > modifier combinations x ASCII characters > > No, AFAIU we only need to support keys+modifiers that are not > otherwise supported already. E.g., C-a is already supported, so we > don't need to add it, and similarly many other combinations are > already supported. Or what am I missing? > -- Alex Hutcheson alexhutcheson@google.com