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.
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.