I tried kakoune on the basis of a blog post I found here a while back, that described its better-thought out Vim-like command language. I was hooked almost immediately. Now I use it daily. So if you like Vi/Vim's text editing model but wish its language was more orthogonal and powerful, give Kakoune a shot.
I started using Kakoune a few of years ago, after a decade+ of Vim, and while the improved command language is nice, the parts of Kakoune I love are:
- dedication to quick feedback
- scriptability and plugins
By "quick feedback" I mean things like multiple selection support, so you can tweak and polish a complex search-and-replace and inspect each step of the process as it happens, instead of writing a complex regex, undoing, and starting again from scratch.
I also mean things like pervasive completion and tool-tips. When I type `:set` I don't just get tab-completion of option names, I get a browsable list of option names and a tooltip describing the syntax of the `:set` command. And once I pick an option, that option's docstring is added to the tooltip so I can see what values the option expects.
By "scriptability and plugins" I mean there's no special directory structure to make a plugin - just take the commands you'd type in the editor, stick them in a `.kak` file in `~/.config/kak/autoload` and you've got a plugin you can share with your friends. If you have a complex editing operation you want to script, you don't need to learn a whole different "long-form" syntax for each command, you can just say `execute-keys` and write out the keys you would press to do the thing. There's more ceremony and polish you can add if you want (like all the fancy completion built-in commands have) but the effort required to automate my tasks is damn near zero.
The multiline cursor is a great tool I didn't know I needed before I tried Kakoune. Also, the commands are more logical. Go to end of line with gl, select code from current place until the end of line with GL, go to the start of line with gh, go to the end of file with gj and to the top with gk, etc. It's more logical and the fact that you can use visual select by keeping shift down when moving is very nice.
I think multicursor is more flexible. I can visually select N lines and use regex to place the cursors and then modify the text in multiple places simultaneously. Kakoune also provides a multicursor similar to the visual block mode that Vim offers but I find myself using that only in very specific situations like "these 5 lines should all start with this keyword" or whatever.
That's shocking to me. Ctrl-D in visual studio code and alt-J in jetbrains are some of my most used key combinations. Even alt-click in visual studio code is sometimes extremely useful. It's like the ability to record and play back a macro multiple times, except you do it interactively and can see / fix / add things as you go.
That's also what I thought as a Vim user before I had access to Kakoune's multiline editing. It changed my mind and might change yours too if you give it a chance
I used editors with multiline editing capabilities in the past.
There are only 2 usecases where it was of any value to me: If I have to write multiple lines in a similar fashion, or if I have to edit the same thing in a similar fashion in several places at once.
Both can be done much easier by using a regular expression.
I disagree. In the past I've used regex to do that and now that I have access to a multicursor, I won't be going back. I think with regex you don't get the same kind of visual feedback that you get from a multicursor which is why I (and many other Kakoune users as well) like it so much. If you're happier with regex and feel like you don't need multicursor, that's great.
Ditto. I rarely use multiple cursors in other editors, but I use them _constantly_ in Kakoune. I have been using it for multiple years. The composability of the command language is what makes it shine.
I find it extremely subjective. "delete word" is much better than "word delete" imo.
Also `dw` sounds more logical if you think about user input speed\pauses. If I press `w` I want to move to the next word immediately. In case were `wd` deletes a word - there should be some lag, no?
Doing the motion first lets you visually confirm the range before invoking the command. You also have the opportunity to adjust the range if you didn't get it quite right.
Mnemonically the vim order works better for English but in practice I find the visual feedback from selection better for anything even moderately complex. An example would b `f` or `t` since I tend to hit the letter I was aiming for earlier than I was expecting.
> In case were `wd` deletes a word - there should be some lag, no?
There's no animation or forced latency. For a short motion that's predictable like `w`, you're typing the d before you actually check the result and it's just as fast as vim but in the opposite order.
> Doing the motion first lets you visually confirm the range before invoking the command. You also have the opportunity to adjust the range if you didn't get it quite right.
It should be noted here that Vim more or less works like this in visual mode. If you go "v <motion> <command>" instead of "<command> <motion>", you can visually confirm the range. I can see the argument that it should be the default, though I like the fact that <motion> alone in normal mode just moves you around without preparing for a command.
Lowercase w resets (each) selection to end of selection, skips any whitespace, and selects to next word boundary, so www or 3w will select third word counting from cursor. Uppercase W extends selection over any whitespace and then to next word boundary, so WWW or 3W will select from cursor to third end of word. (Most other movements are also in lowercase resetting / uppercase extending pairs.) Thus with length-1 (that is, initial-state) selection you can do wwwd or 3wd to delete third word and preserve whitespace, wWWd or w2Wd to delete three words but preserve whitespace, WWWd or 3Wd to delete three words and any whitespace between cursor and start of first word.
That is, counts work, it’s the movements that are slightly different. See manual §3.4–6[1].
>There's no animation or forced latency. For a short motion that's predictable like `w`, you're typing the d before you actually check the result and it's just as fast as vim but in the opposite order.
Yeah, I just realised we are talking about normal mode basically...
> I find it extremely subjective. "delete word" is much better than "word delete" imo.
Yes, as single command typed in isolation whether dw is better or wd is better is a matter of personal subjective opinion.
But, where object-verb (wd approach) becomes objectively better is that it composes with subsequent editor commands in a way that verb-object (dw approach) does not.
Editing is all about performing operations on text. You can first make increasing complicated selections, review them as they are being built up and then decide what to do with them in the end with the object-verb paradigm.
All this is difficult to describe textually. Try to checkout some Kakoune editing on YouTube or do it yourself by looking at the TRAMPOLINE tutorial [1] and you might come around to the `wd` school of thought!
> which matches well with the visual feedback Kakoune gives you.
Do you really need this feedback though? I can understand this when yanking, but if I'm going to delete the word... The whole action take much less that a second and then I proceed with my task.
You're taking the example too literally. The point is that using the motion first gives opens the possibility of visually confirming what the action will be taken on. The usefulness of that improves when the motion is complex. But nothing forces you to confirm, so if you're confident it's right you can immediately follow the motion with the action. That loses you no time compared to Vim.
I agree that in this kind of case motion first may be a way to go. Basically it should look like `search && replace`. Without actually doing search && replace.
Even in the case of simple "wd", sometimes I have multiple cursors I am operating on at the same time (e.g. from complex regex or just through selecting multiple lines at once) so each cursor could point to fairly different things. Then, the visual feedback becomes very useful.
The benefits pile up quickly when you want to do something even slightly more complicated. Hit w a bunch of times until the selection looks right, rather than count words. Tweak either end of the selection to catch spaces or punctuation.
You can do all this in Vim, I'm sure, but it's less mental effort in kak, because to a much greater extent you can see the results of your actions before they happen. And it's no slower if you do happen to know exactly what you're doing, because it's almost the same keystrokes in different order.
