Note that point three above applies to both the functionKeyNames and keyNames arrays in file pkg/ui/key.go. Which also means, for example, that enter, eNtEr and Enter would all be legal if a case-insensitive match of those tokens was performed.

Honestly, I have very mixed feelings about the case-insensitive matching. It is "friendly". It also enables obfuscation. It could even be a security hole. Consider Unicode letter aliasing to mislead readers of a URL (or other text). I'm leaning towards making matching a modifier prefix case-sensitive. That is, you have to write Alt- rather than alt- or aLt-.

I'm in support of case sensitivity, if only for aesthetic reasons. So long as documentation for bindings lists the proper form of Alt-Left as an example, it will be obvious what is expected. Given the relative rarity of configuring bindings, I'm unsure of this leniency's usefulness. Honestly, as a beginner, your typical Elvish user will have much worse problems (coming from POSIX compatibles or even fish, scripting is a nightmare here).

The Alt key is typically represented by an M- prefix, e.g. in GNU Bash, EditLine and Emacs. (Elvish has inherited this mapping from Meta to Alt.) A prefix of \e also often works. Similarly for Ctrl, the standard happens to be C-, with an alternative of ^ that is only really suitable for a range of ASCII characters.

The aforementioned software does not even understand Alt-, Meta- or Ctrl-. So it could be said that the full-length names are excess friendliness. Or that the one-letter prefixes act as backwards compatibility, whichever you prefer.

Case insensitivity and short modifier names are useful when typing out key names in the CLI, and that's likely the only place it's useful.

If there is a mode to insert the name of a key in the CLI - say pressing Ctrl-L inserts Ctrl-L, we can get rid of case insensitivity and short modifier names.

Converting literal key sequences to the symbolic name would be cool and useful. The fish shell ships with
the fish_key_reader program that does just that. However, I don't think there is any reason simplifying the implementation to remove the short modifier names and/or make the matching case sensitive has to be predicated on that capability. Consider that there is probably no one other than yourself, @xiaq, who has been using the current behavior since it is undocumented. Too, the key name must still be spelled with the proper case; e.g., Backspace not backspace.

I am equally happy with making the key name case insensitive and documenting the behavior. This is simply about consistency and documenting behavior.

P.S., This is an example of the fish_key_reader behavior where I pressed Alt-K:

> fish_key_reader
Press a key

              hex:   1B  char: \c[  (or \e)
(  0.374 ms)  hex:   4B  char: K
bind \eK 'do something'

/facepalm on my part since I just realized that the reason the key modifier can be case-insensitive but the key cannot (at least by default) is because we need to distinguish between letters such as x and X. However, that is easy to finesse by testing if the key name (without the modifier prefix) is a single character or symbolic key name which will always be longer than a single character. In the single char case perform a case-sensitive match else a case-insensitive match.