Hacker News Reader

>In fact, many of the people arguing against multi-cursors have been convinced after trying them that they are better.

Fact by who?

>The basic problem with macros and global replace is that they don't happen immediately and don't give you feedback. I don't know any vim user who hasn't had the distinct pleasure of needing 3 tries to record a macro before they got it right.

True about macros, which are a very powerful tool that's way more than just multiple cursors. For global replace, however, this is false. Vim has an option to enable visual feedback for select/replace commands. I use it every day and it's awesome.

>What's more, if I record a macro and run it, then realize after it that I want to do a small addition, I have to go through all the "setup" steps again - go back to the start, re-record, add the logical of finding the next block, and so on. I can't just visually see the situation and say "oh yeah, why don't I add this little tweak".

What about recording the rest of the macro and running both of them one after the other?

>Seriously, take a very common example: having 3 if's one after the other, where you want to add a line at the start of each if block. Doing this with multiple cursors is a breeze - 3 buttons and you get 3 cursors, then write your code. And if, after writing it, you realize you actually want to add another line, you just keep typing. It's literally the same as typing.

v<linenum>j:s/if/<whatever>if/g oh wait, I wanted to add another line? uv<linenum>j:<up><change regex>

Also as somebody already pointed out, vim already has plugin(s) for multiple cursor support and they work exactly as they should. I'm not arguing against multiple cursors, I'm just saying that they don't really bring anything new.

Just to add to that, you can also use visual block mode to change text on multiple lines. You get a lot of the benefits of multiple cursors that way while still doing things in a more traditional "vim-like" way.

No reason not to do things in a vim-like way with multiple cursors. In fact, they're literally just an extension of the block-mode concept, except that it's just better because it allows you to do a superset of things.

They don't bring anything new in the same way a repl doesn't bring anything new to a edit/compile/run cycle. Instant feedback is just better.

>Fact by who?

By me. I've talked to people and they've changed their minds. Sorry, should've made that explicit.

>What about recording the rest of the macro and running both of them one after the other?

Because sometimes you only think of it later.

>Also as somebody already pointed out, vim already has plugin(s) for multiple cursor support and they work exactly as they should. I'm not arguing against multiple cursors, I'm just saying that they don't really bring anything new.

As I mentioned to them, I used that plugin, and while it's awesome and I totally love the author for making it, it just isn't as good. See my other comment for details.

And again, I really disagree that they don't bring anything new. That's like saying that WYSIWYG text editors don't bring everything new over systems like Latex. Can you do everything in both systems? Yes. Is it sometimes easier to just select text and hit "ctrl+b"? Yes. Is it always better? No. But it's good to have both options, as sometimes one crushes the other.

Again, I love vim, and I definitely use some of the very methods you've mentioned. But I'm not here to sell you anything, I don't earn anything by convincing you to at least give multiple cursors a shot, except knowing that if you're dismissing them without having tried them then you're missing out and that makes me sad.

> [I] have a 1500 line vimrc and plenty of plugins (including my own), so you don't get to assume I don't grok the vim way of thinking :)

This may only show that you grok VimScript way of thinking, not Vim way of thinking.

You need not re-record a macro, a macro is stored in a register. Just edit the register, and you're good to go with you new, (supposedly) improved macro.

In Vim, you edit in Normal mode, and insert in insert mode. Multiple cursors is a means of moving editing into insert mode, and thus in spite of the Vim way. I am an Emacs user * and there is a multiple-cursors mode for Emacs, which quite useful as Emacs is modeless.

* If we're doing SLOC porn here, I've a ~400 SLOC vimrc with nice gems in it, and is nicely and extensively commented. I've switched to Emacs for my love of Lisp and newfangled dislike of some parts of Unix.

My .vimrc used to be large, but now has dwindled down to a handful of simple commands. I've simply adapted to be maximally productive in a nearly pure vim environment. Does this make me less of a vim user?

It rather makes you more of a vim user. My vimrc file contains mostly leader mappings and option settings, added mostly with a craze of customising.

"This may only show that you grok VimScript way of thinking, not Vim way of thinking."

True enough that it doesn't prove anything.

"You need not re-record a macro, a macro is stored in a register. Just edit the register, and you're good to go with you new, (supposedly) improved macro."

I know. And if you think this process is easier, faster, or saves keystrokes over using multiple cursors, then I think you're wrong.

"In Vim, you edit in Normal mode, and insert in insert mode. Multiple cursors is a means of moving editing into insert mode, and thus in spite of the Vim way."

No no no! That's the beauty of using multiple cursors in vim. You can have (potentially) multiple cursors in Normal Mode, and use all the normal vim commands. That's what makes it so sad that it doesn't have multiple cursors, because if you can merge the power of multiple cursors with the power of vim, you get something amazing.

Imagine having the following:

<pre>

<div>some text</div> <div>Some other text</div> <div>Third</div>

</pre>

Then imagine you want to, for some reason, copy-paste the contents of the different divs into (say) another buffer.

With multiple cursors, you can select the three lines, use the vim commands to yank the text object that's in between the divs (yit), and then paste it elsewhere. This is not possible in Sublime Text, since it has no way of saying "select text between divs". Or even, doesn't have vim's "f" command so one could jump to the "<" character opening the second div.

Well, I can copy the divs over, then run ":'<'>s/<\/\?div>//g". Or, if the divs were aligned nicely, I'd copy the divs except for the opening tags via block selection, then on the result of pasting, I'd run ":'<'>s/.\{6\}$//". The difference with the multiple-cursors way and the Vim way is that, the above regexps can be used, without modification, on ranges of variable amounts of lines, whereas, the multiple-cursor way is not as flexible to get adapted to handle variable amount of lines as far as I can imagine.

Vim poses a way to edit text; Sublime, Emacs and other modeless editors pose another. One enables neat tricks via a very nuanced and powerful editing language, that is Vim verbs, text objects et cetera, and the rest do not provide such mechanism, in favour of simplicity and ease of use (it is easier to start typing in Emacs than Vim, whereas it is easier to do editing in Vim than Emacs, but only for the knowledgeable user).

Do not get me wrong, I am not thinking multiple-cursor-editing is useless; in fact, I use it quite a lot in Emacs[1], and I like how it indeed helps me do my multi-line editing with instant feedback. My argument is that such editing has little to offer to a user that has spent a month-or-so to master Vim.

[1]: https://github.com/magnars/multiple-cursors.el

> What's more, if I record a macro and run it, then realize after it that I want to do a small addition, I have to go through all the "setup" steps again - go back to the start, re-record, add the logical of finding the next block, and so on. I can't just visually see the situation and say "oh yeah, why don't I add this little tweak".

this is very doable, lets say you record a macro to 'a'

    1. q:
    2. let @a='
    3. ^r^ra to put in the current contents of the macro
    4. edit as you see fit

    --- you should now have something like ---
    let @a='contents of macro'
    
    5. ???
    6. profit