Enable remapping of Ctrl-C and Ctrl-G #5107
Conversation
I dedicate any and all copyright interest in this software to the public domain. I make this dedication for the benefit of the public at large and to the detriment of my heirs and successors. I intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law.
This allows the user to choose different interrupt and cancel keys, allowing <c-c> and <c-g> to be mapped to something else if desired. These two options are only applicable at the global scope.
doc/pages/options.asciidoc
Outdated
| *key*:: | ||
| a single keypress using the same syntax as `map` (see | ||
| <<mapping#mappable-keys,`:doc mapping mappable-keys`>>). If | ||
| multiple keys are entered, only the first will be used. |
There was a problem hiding this comment.
If multiple keys are entered, only the first will be used.
I think it's better to throw a runtime_error{"too many keys"}, then we can delete this line from docs.
There was a problem hiding this comment.
I changed it to require exactly 1, following the example of codepoint. However, I just realized that does prevent determined users from disabling it altogether if they want. Should set global interrupt_key '' be allowed, with a caveat of "be it upon your own head"?
| @@ -47,13 +47,14 @@ Client::Client(std::unique_ptr<UserInterface>&& ui, | |||
| m_ui->set_ui_options(m_window->options()["ui_options"].get<UserInterface::Options>()); | |||
| m_ui->set_on_key([this](Key key) { | |||
| kak_assert(key != Key::Invalid); | |||
| if (key == ctrl('c')) | |||
| auto opts = context().options(); | |||
| if (key == opts["interrupt_key"].get<Key>()) | |||
There was a problem hiding this comment.
so this means that if a user really wants to, they can map it to different
keys in different modes with ModeChange hooks.
I wonder if we want to make this more ergonomic, I don't have a strong
opionion on this, this seems fine.
I guess <c-g> is only ever useful in normal or prompt mode, so it likely doesn't matter.
There was a problem hiding this comment.
If a good way to sugar it occurs to us later, it could be added at that point, right?
| @@ -837,7 +837,9 @@ The following keys are recognized by this mode to help with editing | |||
| These keys are used to cancel long-running operations, either inside | |||
| Kakoune or outside it. Because they are intended as a safety mechanism | |||
| when something goes wrong, these keys are handled very early on in | |||
| Kakoune's input processing, and therefore cannot be remapped in any mode. | |||
| Kakoune's input processing, so they can only be remapped by changing | |||
There was a problem hiding this comment.
So this allows us to maybe make commands like map global normal <c-c> ...
throw an error if cancel_key=<c-c>, and point to that option.
Not sure if we want to do this; it would be a bit more user friendly on one
hand but also enforce an ordering of map/set-option commands in kakrc which
would be weird.
There was a problem hiding this comment.
Yeah, this sounds like it would introduce a little more complexity on both the user's and Kakoune's side. I do wonder if maybe the pointer about "warning, these two behave differently" belongs near the top of :doc mapping rather than at the very bottom of :doc keys?
(following the example of "codepoint")
The interrupt and cancel keys cannot be remapped because they are processed by the Kakoune client before reaching the input manager. (As noted in a comment, processing them early is intentional.)
This PR adds two options,
interrupt_keyandcancel_key, which can be used to customize which keys are used for these purposes, freeing the defaults up to be mapped to another action using themapcommand. This approach ends up requiring fewer code changes (+27/-3) than the earlier work in #4909, and it keeps the processing of these keys early and uncomplicated.(Note: I'm experienced with C but not C++, so feel free to educate me if I've written anything unidiomatic.)