Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document and normalize handling of symbolic UI key names #1163

Closed
krader1961 opened this issue Sep 30, 2020 · 5 comments
Closed

Document and normalize handling of symbolic UI key names #1163

krader1961 opened this issue Sep 30, 2020 · 5 comments

Comments

@krader1961
Copy link
Contributor

@krader1961 krader1961 commented Sep 30, 2020

While looking into issue #912 I noticed three aspect of symbolic UI key names that needs some discussion. Here I'm talking about a binding map assignment in a statement such as edit:insert:binding[Alt-Left] = { echo alt-left >/dev/tty }.

  1. The modifier prefix letter-case doesn't matter. You can use Alt-, alt-, aLt-, etc.
    *) I think this behavior is desirable and should be retained. It also needs to be documented but non-canonical letter-case should be discouraged.
  2. There are undocumented modifiers. For example, you can use a- (or A-) instead of Alt-.
    *) Whether these shortened aliases should be retained is an open question. When I proposed allowing [d] or [type:d] as shorter forms of the [type:dir] wildcard modifier @xiaq rejected adding those aliases. It seems like the symbolic key names should also, if we're going to be consistent, not allow single letter modifiers; i.e., A- should not be an alias for Alt-.
  3. Function key names must match the letter case exactly. For example, Left is okay while left is not.
    *) I think the behavior should be modified to perform case insensitive matching of those names.
@krader1961
Copy link
Contributor Author

@krader1961 krader1961 commented Sep 30, 2020

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

@pjanx
Copy link

@pjanx pjanx commented Oct 14, 2020

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.

@xiaq
Copy link
Member

@xiaq xiaq commented Oct 14, 2020

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.

@krader1961
Copy link
Contributor Author

@krader1961 krader1961 commented Oct 15, 2020

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'
@krader1961
Copy link
Contributor Author

@krader1961 krader1961 commented Oct 21, 2020

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

krader1961 added a commit to krader1961/elvish that referenced this issue Oct 22, 2020
Document the format of key names. Make function key name matching
case-insensitive for consistency with how key modifers (e.g., "Alt")
are handled.

Resolves elves#1163
krader1961 added a commit to krader1961/elvish that referenced this issue Nov 9, 2020
Document the format key of names and modifiers; albeit with a TODO
regarding the `Shift` modifier.

Make function key modifier matching case sensitive (`Alt` not `alt`)
to match key name matching (`Enter` not `enter`).

Implement `Ctrl-?` as the logical counterpart to `"\c?"`.

Resolves elves#1163
@xiaq xiaq closed this in #1177 Dec 25, 2020
xiaq added a commit that referenced this issue Dec 25, 2020
Document the format key of names and modifiers; albeit with a TODO
regarding the `Shift` modifier.

Make function key modifier matching case sensitive (`Alt` not `alt`)
to match key name matching (`Enter` not `enter`).

Implement `Ctrl-?` as the logical counterpart to `"\c?"`.

Resolves #1163
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants