Sublime Text style multiple cursor select/add mapping


sometimes it feels more natural to select word and jump to next occurence(s), so instead of doing <a-i>w*<s-n><s-n><s-n>... multiple times I use this command:

define-command -override -docstring "select a word under cursor, or add cursor on next occurrence of current selection" \
select-or-add-cursor %{ execute-keys -save-regs '' %sh{
    if [ $(expr $(echo $kak_selection | wc -m) - 1) -eq 1 ]; then
        echo "<a-i>w*"
        echo "*<s-n>"

map global normal '<c-d>' ': select-or-add-cursor<ret>' -docstring "add cursor on current word, and jump to the next match" 

Basically what it does, is if the selection is only one char, it selects current word. If selection is more than one char, then the same shortcut will select next occurrence. It can’t select single letter items though, but I never thought I need it, since I can *<s-n> which is just one key more. It also adds more control since selecting regions and then filtering it will select all occurrences, but here we have more control since we can skip some words if we need.

Command strategy for `if`

I added this on my kakrc.
Don’t know if it should be add to Kakoune ?


No. It is fine to use this as a mapping.


Don’t want to sound controversial, but I kind of agree with @lauccode.
This is one of the features that made Sublime successful. It’s there, it’s discoverable, and just works w/o configuration.

I’d expect:

  • <c-N> to keep selecting inner word
  • <a-N> to skip the currently selected token and jump to the next matching one.
    Not married to the mappings, just providing an example.

If Kakoune’s goal is to really reduce the number of keystrokes and make multi cursor editing the default way of thinking, this would be a good candidate.


I can make a plugin of it, but one of goals of kakoune is to force users to experiment and build solutions of problems that they encountered. Like this one. It’s fairly simple and gives me what I want. And kakoune has all needed building blocks to do such and more complex stuff. Unless this stuf is too complex to implement by semi-average user, such things will never really be in kakoune.


I don’t disagree with you, just saying that such a core feature being built in would potentially increase adoption, which is good for the editor and the community.

If everyone is going to implement it in the same way, it might make sense to be built in rather than re-implemented over and over.


Kakoune goal is also to have consistent set of normal command. Your proposal would break the orthogonality of the n command which follow the same pattern than other: shift extend and alt go backward. (same behavior for f, t…)


For some unexperiment user of Kakoune and some persons which would like to have an editor “key in hand” it should be nice to have a sort of set of plugins with associated kakrc ?
Maybe it is too early to speak of “kakoune distribution”.
This should avoid to break Kakoune goal.


In my experience every of such distributions were a bad thing. They are slow, overengineered and usually are not working how I really want it to. The power of Vim is that you can make it work how you like. The power of Emacs is that you can make it work how you like. The power of Kakoune… do I need to continue, it’s obvious.

The power of distribution on the other hand is that you don’t need to configure it, but that’s not the kind of power I want. So distributions are bad thing in my opinion.

I’ve heard a lot of thoughts in a way that “if you want a distribution of editor instead of configuring editor, then this editor isn’t for you”. I don’t fully agree with this, because such distribution can show some capabilities in editor customization, and user may switch to vanilla once he figures out what he wants, but generally it is true, since such users would be far more productive with a simpler editor where everything is done for you mainly by developers.


Recently, lenormf started an ‘out of the box’ project which aims to cover basic needs common to most Kakoune users:


I quite like that approach, it’s more practical than the scattered snippets from the wiki (download a single file and comment stuff as needed), easier to maintain, and it’s an good way for new users to discover functionality with small pieces.


Like said, I’m not married to the mappings. Would love to keep the conversation on if this should be a core feature