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.
Iāve decided to update this post with a more robust version that doesnāt use any shell expansions thus much faster an based on selection only:
define-command -hidden -docstring \
"select a word under cursor, or add cursor on next occurrence of current selection" \
select-or-add-cursor %{
try %{
execute-keys "<a-k>\A.\z<ret>"
execute-keys -save-regs '' "_<a-i>w*"
} catch %{
execute-keys -save-regs '' "_*<s-n>"
} catch nop
}
Iām using this version for a long time already and it works much faster.
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.
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.
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.
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.
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.
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
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.
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.