Sublime Text style multiple cursor select/add mapping


#1

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*"
    else
        echo "*<s-n>"
    fi
}}

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`
#2

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


#3

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


#4

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.


#5

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.


#6

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.


#7

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…)


#8

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.


#9

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.


#10

Recently, lenormf started an ‘out of the box’ project which aims to cover basic needs common to most Kakoune users: https://github.com/lenormf/out-of-the-box


#11

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.


#12

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


#13

Is that a goal? I hope it is not. A focus on consistency and orthogonality and hence a degree guess-ability – that is what brought me to Kakoune and what keeps me here. Whenever @mawww has to break something to make it more consistent or more orthogonal I am always in favor of it.


#14

I think that I’ve started to think this way after seeing this comment: https://github.com/mawww/kakoune/issues/1038#issuecomment-269011973


#15

My understanding is that Kakoune’s values are generally minimalism and orthogonality and extensibility over completeness and easiness and integration.

Kakoune is often weird and surprising, but not gratuitously. It’s not like a puzzle in a video game, deliberately obscure for the sake of obscurity, but because Kakoune is meticulously following its own rules. It may be different to other editors, or even objectively worse than other editors, but Kakoune is doing the Most Kakoune Thing.


#16

I read that as a nod to minimalism, Kakoune won’t do everything. That said, if it doesn’t do “enough” Kakoune Distributions will become a thing – and down that path is pain. I think there is some stuff Kakoune has that seems crazy (but awesome) to my vim tastes like alignment. The line between fundamental and extraneous is always personal, but you have to try to strike a sane balance.


#17

With current approach Kakoune is editor for tinkerers. You get decent experience out of the box and a lot of building blocks to customize it.

It’s not over-complicated like Emacs and It has sane defaults in contrary to Vim. If we ever see Kakoune distribution it will probably be targeted at users who don’t want to tinker and customize, just get job done.

I doubt it will huge monstrosity like Spacemacs tho. If I’d like to create SpaceKakoune today, targeting users who don’t like to tinker I would bundle:

  • plug
  • expandtab
  • surround
  • create directory on save
  • tab, shift-tab to cycle through completions
  • system clipboard support
  • line numbers by default
  • modeline-parse and editorconfg-load on buffer load

It’s quite short list I think


#18

And then we all doomed. People are complaining about things, but when distribution arrives people complain about distribution and then new distribution arrives and people complain about… It’s never ending. There are already Spacemacs, Doom Emacs, Prelude, Frontmacs, Emacs-live, Purcell’s .emacs.d, Emacs24 Starter Kit, Oh-My-Emacs, Cabbage, Graphene, Ohai Emacs, Emacs-Bootstrap, Scimax, better-defaults and possibly more of *macs distros. It’s great for diversity but it is essentially the same as sharing your configuration file, and believe me, no way your particular config will be comfortable for everyone. Usually distributions are bad thing, that breaks community. Vim has less distributions because it is less hackable compared to Emacs and it is more complete than Emacs out of the box. I think that’s the direction that should be adopted by Kakoune.

And by the way, that’s really bothers me when you call a distribution of some editor a SpaceEritor. That’s wrong approach. Spacemacs And SpaceVim are called this way only because they use space key as centric way of interaction with commands. It’s unnecessary to call Kakoune distribution “SpaceKak” unless it uses Space and mnemonic shortcuts like in Spacemacs or SpaceVim. For Kakoune to become a SpaceKak, it doesn’t even need to have all this fancy stuff like plugin management and other tweaks - only the space key as a global shortcut leader and a mnemonic groving narrowing system for them.


#19

I think kakoune is already well done and the philosophy too.
It make me discover tmux and ranger for example. And it is right, why lost time to develop things which are already well done if we can use it.
Maybe continue the wiki to explain how to make it as an IDE with the most used tools should be enough.