mapping a key combination to do nothing #765

mvdan commented 2021年10月23日 23:23:38 +02:00

I have a problem where Control+; (control plus semicolon) does weird things on some apps. For example, see https://github.com/vim/vim/issues/9014. It also seems to do weird things on Bash.

On other shells like dash, I just get the ANSI escape sequence ^[[27;5;39~, which looks right.

Anyway, I don't think foot has a bug, but I have monkey fingers, and when I reach for Control+L I sometimes hit Control+;.

Would it be possible to configure foot so that Control+; is mapped to... do nothing at all? I skimmed foot.ini twice, but I only found ways to map that key combination to existing actions. I guess I could map it to something generally harmless like cancel, but I would rather map it to nothing, such as noop.

While at it, how do you actually write this key combination? cancel=Control+; does not work. The man page mentions "XKB key names", but I can't figure out what that is for the semicolon. cancel=Control+semicolon doesn't work, and neither does cancel=Control+XK_semicolon.

I have a problem where `Control+;` (control plus semicolon) does weird things on some apps. For example, see https://github.com/vim/vim/issues/9014. It also seems to do weird things on Bash. On other shells like dash, I just get the ANSI escape sequence `^[[27;5;39~`, which looks right. Anyway, I don't think foot has a bug, but I have monkey fingers, and when I reach for `Control+L` I sometimes hit `Control+;`. Would it be possible to configure foot so that `Control+;` is mapped to... do nothing at all? I skimmed `foot.ini` twice, but I only found ways to map that key combination to existing actions. I guess I could map it to something generally harmless like `cancel`, but I would rather map it to nothing, such as `noop`. While at it, how do you actually write this key combination? `cancel=Control+;` does not work. The man page mentions "XKB key names", but I can't figure out what that is for the semicolon. `cancel=Control+semicolon` doesn't work, and neither does `cancel=Control+XK_semicolon`.

craigbarnes commented 2021年10月24日 00:21:44 +02:00

I have a problem where Control+; (control plus semicolon) does weird things on some apps. For example, see https://github.com/vim/vim/issues/9014.

It sounds like the issue here, on the foot side at least, is somewhat similar to #628. foot doesn't really implement modifyOtherKeys per se, but it does emit the same kind of escape sequences for certain key combos by default.

It also seems to do weird things on Bash.

Weird as in printing parts of the escape sequence? Or something more than that?

The usual workaround for accidental key combo issues in bash is to add something like the following to your ~/.inputrc:

"\e[27;5;59~": ""

I'm not sure what the vim equivalent of that would be, but I imagine there's something like it.

Would it be possible to configure foot so that Control+; is mapped to... do nothing at all?

It's not possible at the moment, but this kind of issue has come up often enough to suggest it probably should be. I'll defer to @dnkl on that one though.

> I have a problem where `Control+;` (control plus semicolon) does weird things on some apps. For example, see https://github.com/vim/vim/issues/9014. It sounds like the issue here, on the foot side at least, is somewhat similar to #628. foot doesn't really implement `modifyOtherKeys` per se, but it does emit the same kind of escape sequences for certain key combos by default. > It also seems to do weird things on Bash. Weird as in printing parts of the escape sequence? Or something more than that? The usual workaround for accidental key combo issues in bash is to add something like the following to your `~/.inputrc`: ```inputrc "\e[27;5;59~": "" ``` I'm not sure what the vim equivalent of that would be, but I imagine there's something like it. > Would it be possible to configure foot so that `Control+;` is mapped to... do nothing at all? It's not possible at the moment, but this kind of issue has come up often enough to suggest it probably should be. I'll defer to @dnkl on that one though.

dnkl commented 2021年10月24日 09:42:59 +02:00

On other shells like dash, I just get the ANSI escape sequence ^[[27;5;39~, which looks right.

This is the escape sequence for Control+' (the ASCII code for ' is 39).

The expected sequence for Control+; is ^[[27;5;59~ (again, ASCII 59 is ;).

That begs the question: are you typing this on a regular US layout? Or something else? Plain keyboard? Which terminfo are you using?

Or perhaps this was just a typo? The vim issue on github only mentions 27;5;59, but not 27;5;39...

FWIW, regardless of whether I press Control+', or Control+;, bash dumps the escape sequence.

However, I can reproduce the vim issue. But, like you said, this doesn't look like a foot issue.

While at it, how do you actually write this key combination? cancel=Control+; does not work.

Control+semicolon is the correct way. You can use xkbcli interactive-wayland to see the names of keys.

When you say Control+semicolon doesn't work, do you mean foot gives you an error? Or that the cancel binding doesn't work? If it's the latter, I suspect this is related to the "apostrophe" vs. "semicolon" confusion, mentioned above.

Would it be possible to configure foot so that Control+; is mapped to... do nothing at all?

This is slightly different from earlier requests, where people accidentally hold e.g. Shift while pressing Enter, and want that to behave as if they had pressed Enter without a modifier.

Whereas here, the request is to completely ignore a key press. I.e. nothing gets sent to the application. Am I understanding this correctly?

I don't really see a problem implementing it. It'll probably come down to ~3 lines of code...

> On other shells like dash, I just get the ANSI escape sequence `^[[27;5;39~`, which looks right. This is the escape sequence for <kbd>Control</kb>+<kbd>'</kbd> (the ASCII code for `'` is 39). The _expected_ sequence for <kbd>Control</kbd>+<kbd>;</kbd> is `^[[27;5;59~` (again, ASCII 59 is `;`). That begs the question: are you typing this on a regular US layout? Or something else? Plain keyboard? Which terminfo are you using? Or perhaps this was just a typo? The vim issue on github only mentions `27;5;59`, but not `27;5;39`... FWIW, regardless of whether I press <kbd>Control</kbd>+<kbd>'</kbd>, or <kbd>Control</kbd>+<kbd>;</kbd>, bash dumps the escape sequence. However, I _can_ reproduce the vim issue. But, like you said, this doesn't look like a foot issue. > While at it, how do you actually write this key combination? cancel=Control+; does not work. `Control+semicolon` is the correct way. You can use `xkbcli interactive-wayland` to see the names of keys. When you say `Control+semicolon` doesn't work, do you mean foot gives you an error? Or that the cancel binding doesn't work? If it's the latter, I suspect this is related to the "apostrophe" vs. "semicolon" confusion, mentioned above. > Would it be possible to configure foot so that Control+; is mapped to... do nothing at all? This is slightly different from earlier requests, where people accidentally hold e.g. <kbd>Shift</kbd> while pressing <kbd>Enter</kbd>, and want that to behave as if they had pressed <kbd>Enter</kbd> without a modifier. Whereas here, the request is to completely ignore a key press. I.e. **nothing** gets sent to the application. Am I understanding this correctly? I don't really see a problem implementing it. It'll probably come down to ~3 lines of code...

mvdan commented 2021年10月24日 11:21:49 +02:00

It sounds like the issue here, on the foot side at least, is somewhat similar to #628. foot doesn't really implement modifyOtherKeys per se, but it does emit the same kind of escape sequences for certain key combos by default.

I am following that thread :) It does sound related.

Weird as in printing parts of the escape sequence? Or something more than that?

On Bash I use its "vi mode", and Ctrl+semicolon seems to exit its insert mode and toggle the capitalization of the last character. I haven't investigated how it even gets there, and honestly, I don't think it matters.

The expected sequence for Control+; is ^[[27;5;59~ (again, ASCII 59 is ;).

I tried again just now with dash, and I get 59. I'm not sure how I got to 39 yesterday. It was late in the night and I probably fat-fingered it :)

When you say Control+semicolon doesn't work, do you mean foot gives you an error?

Correct. Adding cancel=Control+semicolon results in cancel: invalid key. This is on foot v1.9.2. If I'm misunderstanding how to map keys, perhaps the manual could include a couple of examples :)

Whereas here, the request is to completely ignore a key press. I.e. nothing gets sent to the application. Am I understanding this correctly?

Correct. I don't think it's a good idea to go and teach inputrc, vim, and all other apps how to ignore an escape sequence that I sometimes type by accident.

I'm not versed enough in escape sequences to know whether implementing the kitty protocol would help here. It still seems like a good idea to be able to map keys to "nothing", though, especially given how easy it is.

> It sounds like the issue here, on the foot side at least, is somewhat similar to #628. foot doesn't really implement modifyOtherKeys per se, but it does emit the same kind of escape sequences for certain key combos by default. I am following that thread :) It does sound related. > Weird as in printing parts of the escape sequence? Or something more than that? On Bash I use its "vi mode", and Ctrl+semicolon seems to exit its insert mode and toggle the capitalization of the last character. I haven't investigated how it even gets there, and honestly, I don't think it matters. > The expected sequence for Control+; is `^[[27;5;59~` (again, ASCII 59 is ;). I tried again just now with dash, and I get 59. I'm not sure how I got to 39 yesterday. It was late in the night and I probably fat-fingered it :) > When you say Control+semicolon doesn't work, do you mean foot gives you an error? Correct. Adding `cancel=Control+semicolon` results in `cancel: invalid key`. This is on foot v1.9.2. If I'm misunderstanding how to map keys, perhaps the manual could include a couple of examples :) > Whereas here, the request is to completely ignore a key press. I.e. nothing gets sent to the application. Am I understanding this correctly? Correct. I don't think it's a good idea to go and teach inputrc, vim, and all other apps how to ignore an escape sequence that I sometimes type by accident. I'm not versed enough in escape sequences to know whether implementing the kitty protocol would help here. It still seems like a good idea to be able to map keys to "nothing", though, especially given how easy it is.

dnkl commented 2021年10月24日 11:29:30 +02:00

Correct. Adding cancel=Control+semicolon results in cancel: invalid key.

Ah. Invalid key... where did you add this?

cancel is not a "generic" action; both [url-bindings] and [search-bindings] has a cancel action, and thus you have to put it in one of those sections.

On Bash I use its "vi mode", and Ctrl+semicolon seems to exit its insert mode and toggle the capitalization of the last character. I haven't investigated how it even gets there, and honestly, I don't think it matters.

Sounds like bash recognizes the escape and have an active binding for it? But you're right - it doesn't really matter here.

I'm not versed enough in escape sequences to know whether implementing the kitty protocol would help here. It still seems like a good idea to be able to map keys to "nothing", though, especially given how easy it is.

It would help indirectly; the kitty protocol would give applications a much better way to handle keyboard input. That in turn means we can remove some of our modifyOtherKeys bindings, because applications that care about input can enable the kitty protocol.

Without the kitty protocol, applications have no alternative. If we remove an escape, that key combo is inaccessable to all applications.

> Correct. Adding cancel=Control+semicolon results in cancel: invalid key. Ah. Invalid **key**... _where_ did you add this? `cancel` is not a "generic" action; both `[url-bindings]` and `[search-bindings]` has a `cancel` action, and thus you have to put it in one of those sections. > On Bash I use its "vi mode", and Ctrl+semicolon seems to exit its insert mode and toggle the capitalization of the last character. I haven't investigated how it even gets there, and honestly, I don't think it matters. Sounds like bash recognizes the escape and have an active binding for it? But you're right - it doesn't really matter here. > I'm not versed enough in escape sequences to know whether implementing the kitty protocol would help here. It still seems like a good idea to be able to map keys to "nothing", though, especially given how easy it is. It would help indirectly; the kitty protocol would give applications a much better way to handle keyboard input. That in turn means we can remove some of our `modifyOtherKeys` bindings, because applications that care about input can enable the kitty protocol. Without the kitty protocol, applications have no alternative. If we remove an escape, that key combo is inaccessable to **all** applications.

dnkl commented 2021年10月24日 13:55:52 +02:00

Ah. Invalid key... where did you add this?

I can see why the error message was confusing... in this context, key refers to the action name (as in key=value), not the key(s) Control or semicolon.

> Ah. Invalid key... where did you add this? I can see why the error message was confusing... in this context, `key` refers to the action name (as in `key=value`), not the key(s) <kbd>Control</kbd> or <kbd>semicolon</kbd>.

mvdan commented 2021年10月24日 22:39:17 +02:00

Ah, yup, I had forgotten the section :) I think more examples in the man page would have helped me here, as I'm not particularly used to writing ini files.

And you're right that the error confused me. I kept thinking I was writing the key combination in the wrong way. Perhaps if it said something like the error below, I would have found it easier:

unknown ini key "cancel" for the default section

Or, if I had put it in a section that wasn't right:

unknown ini key "cancel" for section [foobar]

In any case, the noop= feature certainly sounds useful, and I believe it will remain useful even if the kitty changes get merged. I'll start using it when it lands. Until then, font-reset= is a reasonable noop emulator :)

Ah, yup, I had forgotten the section :) I think more examples in the man page would have helped me here, as I'm not particularly used to writing ini files. And you're right that the error confused me. I kept thinking I was writing the key combination in the wrong way. Perhaps if it said something like the error below, I would have found it easier: > unknown ini key "cancel" for the default section Or, if I had put it in a section that wasn't right: > unknown ini key "cancel" for section [foobar] In any case, the `noop=` feature certainly sounds useful, and I believe it will remain useful even if the kitty changes get merged. I'll start using it when it lands. Until then, `font-reset=` is a reasonable noop emulator :)