The GitHub issue referenced below describes the default behavior of
the 'm' key in a way that was unknown to me. As the issue says,
"'m' is a pretty misunderstood key", and goes on to describe how
the documentation makes it sound as if the cursor must be on the
matching character before 'm' will work. However, this is not true;
pressing 'm' will jump forward to "select the next sequence enclosed
in balanced chars". This patch updates the documentation so that it
describes that behavior.
GitHub-Issue: #2425
Special-thanks: Delapouite
Add <c-w> and <a-d> (along with <c-W> and <a-D> that work on WORDs),
and <c-y> which pastes the transient clipboard contant (which saves
big erase, such as word erase and line end/begin erase).
Fixes#2355
In the end, no better solution materialized so far, and custom
Kakoune line editing bindings are hard to remember. Using well
known readline bindings seems just more convenient.
Closes#800, although it does not contain all the binding proposed
by it (I might accept a few additional ones, such as <c-w>, but not
too much, I still see that as a hack pending a nicer solution).
Because keyboard layouts vary, the shift-modifier `<s-…>` is only supported
for special keys (like `<up>` and `<home>`) and for ASCII lowercase where
we assume the shift-modifier just produces the matching uppercase character.
Even that's not universally true, since in Turkish `i` and `I` are not an
uppercase/lowercase pair, but Kakoune's default keyboard mappings already
assume en-US mappings for mnemonic purposes.
Mappings of the form `<s-x>` are normalized to `<X>` when `x` is an ASCII
character. `<backtab>` is removed, since we can now say `<s-tab>`.
