Question - multiple carets

[dvidsilva]

many ST users say that multiple cursors is the most amazing thing in the universe and won't change to an editor that don't support them. I understand why in current vim this is not possible, with the new design changes would it be possible?

[flugsio]

This might be something? (haven't tried it, just googled now) https://github.com/terryma/vim-multiple-cursors

[tarruda]

Maybe this can be implemented as a 'client' feature by a combination of a plugin and a UI that understands multiple cursors.

For example, a plugin could store positions of multiple virtual cursors and intercept keypresses in insert mode, which would cause the plugin to move the real cursor through each virtual cursor 'repeating' the key press. It would also require a bit of support from the UI, since it's required to display the virtual cursors.

At least for initially, it appears that this could be implemented without any modification to the code source code.

[tarruda]

@flugsio that look cool :)

[dvidsilva]

thanks

[Ivanca]

https://github.com/terryma/vim-multiple-cursors/issues/54

Is not that easy. It also requires multiple buffers, like when you copy using (i.e.) six carets and then pastes accordingly in the six current positions.

This also means every caret can have it's own selection and context, so the solution of "virtual carets" is unfeasible because when (for example) a plugin relies on a caret-position-change-event it will break thanks to the wrongly assumption that the event did indeed happen.

---

One advantage of supporting this out of the box is that plugins can be made with this feature in mind, for example plugins that write a sequence of numbers in every caret (first caret: 0, second caret: 1, etc).

@tarruda I'm one of the people that will not use neovim if this is not supported out of the box, I might be a minority but just so you know we actually exist.

[aktau]

It's true that the current plugin implementations of this are not very user-friendly, it's definitely something we should look at to convert sublime text users that are fed up with the glacial pace and closed sourceness of ST. I feel that many of them won't be willing to make the jump to atom, and it would be easy to reel them in with either native multiple cursors support (or a better plugin interface for it) and saner defaults.

[FelikZ]

I can help to write code if someone know how to make it in context of current core architecture?

edit: is there anywhere an option to pledge exactly to this feature? So we can speedup it is deployment by funding it.

[adelarsq]

Something that I miss in the plugin vim-multiple-cursors is the mouse support. The only thing that I miss from ST.

[FelikZ]

@adelarsq does it works good for you? For me its very buggy in many cases (very often cause .. char sequence in all cursor positions) and laggy when use about 10 cursors.. Every change takes about 1-2sec, makes work very uneffective.

[tarruda]

I don't see why this couldn't be implemented as a plugin in neovim. When the UI code is written, we can leave some support for multiple cursors, and a plugin could implement the logic behind it.

I may be wrong, but implementing something like this into the core would be hard, at least for now.

[adelarsq]

@FelikZ actually it's good only for little changes.

Any support from editor would be good for performance reasons. Mouse support may be done by plugin? I don't know.

[FelikZ]

@tarruda in current vim implementation there realy many fundamental problems, just look at list of issues in this plugin.

[Ivanca]

If you want to have a chance in becoming the one "true and only" editor this should be supported out of the box, maybe you haven't realized the magnitude of how important (and efficient) this is for many of us so here is a little gif. Much of the things are actually faster than (vanilla) vim when you wrap your mind about how useful having multiple context/buffers/selections is.

[justinmk]

@Ivanca

Neovim's first and primary goal is to modularize the core of vim, which will enable plugins to do all kinds of fancy things, such as multiple cursors. Requesting random UI features in this issue tracker, is just noise.

[felipecrv]

@Ivanca implementing this as a plugin will make it work out-of-the-box. The plugin will be distributed along neovim. @tarruda argued that it will be easier to implement as a plugin on top of a cleaner and more powerful neovim codebase.

[Ivanca]

Random UI features

This is not UI at all, this is n* amount of vims working at the same time; because the commands actually apply in every instance of the carets.

I would like to have a way to fund this feature. I would be really glad to do so.

[justinmk]

this is not UI at all, this is n* amount of vims working at the same time

That's a good point. I guess my point is: many things will be possible after the "vim as a library" concept is implemented. But AFAIK new features won't be added until after the priorities listed on the project page and the fundraiser page.

[Ivanca]

Fair enough. I'm just (like always) craving for the existence of a one-true-and-only code editor and there are very few editors being created from scratch so I couldn't miss this rare opportunity to speak up to the developer in charge; even when its goals are a bit different is hard to deny that multiple carets + VIM wouldn't be a match made in heaven .

[aktau]

@Ivanca trust me Ivan, there are plenty of us who have at one time used (or still use it sometimes) Sublime Text. Multiple selection is (for me) the best feature Sublime Text has, and I think many would agree. It would be heaven if neovim had it as well. What everyone is saying is that the codebase is not in a condition to be adding features right now, first we have to make sense of all the mess.

[FelikZ]

I am not very fimilar with bountysource resource, but maybe there an option to add special pledge for this feature? I think many people will want to fund it separate to main goals. Maybe even someone will accept the challenge to write it in parallel?

[kapral18]

All of this talks remind me of how the jetbrains fan community attacked the creators, begging them for implementing the multiple cursors feature out-of-the-box, and you know - few years passed and they finally did it, @tarruda just repeats the same things jetbrains officials said back to that days, but the truth is that its a must-have thing that must be implemented out of the box side by side with other regular vim features, let it be the neovims distinguishing one and definately worth donating.

[tarruda]

@kapral18 I'm not familiar with jetbrains, but if their codebase was nearly as chaotic as the one we've inherited, I'd say they were right to wait a few years.

@FelikZ It's not only a matter of pledging. It would be extremely difficult integrating such a feature in the current code.

I'm not saying it will take years for this feature to be available in neovim, as I mentioned in my previous comments I even have a few ideas on how this may be implemented as a "new-style" plugin(with proper support from the UIs), which would be a lot less error-prone than messing with a very obscure part of the C code.

After my goals for the first iteration are achieved I might even take such task for myself. If the majority of the community feels this is a necessary feature, it will probably be bundled with the official distributions of neovim.

Personally, I don't see any productivity gain by using multiple cursors over plain old vim macros. It's probably more beginner-friendly though and certainly has the "eye candy effect".

[moljac024]

@tarruda Similar productiveness (in some cases) but much more beginner-friendly and eye-candy effect? That sounds like a plus to me :)

[tarruda]

@moljac024 I don't think multiple cursors are nearly as powerful as macros are.

I just said they can be used to do some of the things that can be done with macros

[aktau]

Both can coexist of course, for tasks that can be accomplished with multiple cursors, they are invariably the way I do it. They require no context switch for me. Macro's have to this day not become second nature.

[Olivia5k]

As a small aside in regards to macros, I wouldn't need this feature at all if :%s and friends would update the buffer in real-time. :hamster:

[simendsjo]

@thiderman That would be very valuable. I often have to undo and redefine - live preview for the win!

[Ivanca]

This is just... you can't be serious... macros are an extremely inefficient way of doing things: https://www.youtube.com/watch?v=eWfBWg8bVTQ

Just look at how he does the replacements, he actually has to count how many times the macro will be applied with no visual feedback to see if its the correct amount of times... unsurprisingly it is not. And if your macro has a problem you have to record it all over again, with multiple carets you don't have any of those issues because you edit them all at the same time, and that includes undoing your mistakes.

Compare that video with this one. I just select one ";" and then holding down ctrl+d to select the next occurrences as much as you need, literally in less than 10 seconds.

Macros complement multiple carets really nicely but by themselves usually are clunky.

[felipecrv]

Macros are not more efficient to solve the problems multiple cursors can solve. That's the price of more power: complexity. But macros can do more than multiple cursors can. As soon as multiple cursor is implemented, I'll be using it! But I will still be using macros. I can remember macros I used yesterday to solve a problem in which multiple cursors wouldn't be of any help. On Mar 6, 2014 8:56 AM, "Ivan" notifications@github.com wrote:

This is just... you can't be serious... macros are extremely inefficient way of doing things: https://www.youtube.com/watch?v=eWfBWg8bVTQ

Just look at how he does the replacements, he actually haves to count how many times the macro will be applied with no visual feedback to see if its the correct amount of times... unsurprisingly it is not. And if your macro haves a problem you have to record it all over again, with multiple carets you don't have any of those issues because you edit them all at the same time, and that includes undoing your mistakes.

Compare that video with just selection one ";" and then selection the next ones holding down ctrl+d as much as you need, literally in less than 10 seconds.

[image: wtf]https://f.cloud.github.com/assets/907138/2344689/3fdb08ae-a526-11e3-9a84-c0fccb1ca304.gif

Reply to this email directly or view it on GitHubhttps://github.com/neovim/neovim/issues/211#issuecomment-36849532 .

[Ivanca]

Wanna bet? Give me the problem and I will show you how I can do it using only multiple cursors (but let's be clear, in real life I use both things combined... like everyone should be doing already)

[tarruda]

@Ivanca ok, how would you do this using multiple cursors.

[Ivanca]

I don't need multiple cursors for something so simple, the standard options of a decent editor are enough.

Just so we are in the clear selecting the full line is an standard option in Sublime Text (and many other editors) as well as the duplication, I didn't record anything by myself. If your concept of macro includes everything an editor does... well, that's just a slippery slope.

[moljac024]

@Ivanca I think you missed the point, what if the text on each line was different?

[Ivanca]

That's different: In that case multiple cursors would come into play.

[tarruda]

@Ivanca nice, so each cursor has it's own paste buffer? I didnt expect that.

Let's make things a little bit more interesting, how would re-run that with a single keystroke later(eg: in another editing session)?

[moljac024]

Wow, that's nice.

@tarruda By saving it all in multiple-cursors aware macro, of course. ZING!

[aktau]

@tarruda as far as I know, these multi-cursor commands can't be macro'd (saved) in the way you specify. The thing is that you usually don't do that, the amount of mental effort and keypresses needed when working with multiple cursors is so low that it takes over a lot of macro functionality at lower cost. What you're talking about is exactly the sort of use-case where macro's are nicer. Multicursors are so friction free to use that if there were 2 or 3 occurrences in the project where I had to do such an operation, I would just repeat the keystrokes with multiple cursors. Not DRY, but very easy and quite fast.

To give an estimate:

For 95% of all usecases where both multiple cursors and macro's can be used, multiple cursors are easier and more intuitive for 95% of all users. For all usecases where only macro's can be used, macro's are better (naturally...).

Macro's may subsume multiple cursors, but that doesn't mean multiple cursors wouldn't be nice ;)

[tarruda]

Ok you guys win, I admit multiple cursors would boost the productivity given by macros

[Ivanca]

Yeah, you would save the process in a macro, and then every cursor would apply the macro.

But I do many things in HTML, JavaScript, Python and after a while you realize is not smart to use so many macros because I would have to remember all the custom key shortcuts and all their caveats (does this macro includes a new line? does it needs to be at the beginning of the line or at the beginning of indentation?), plus none of those macros would exist in other PCs.

Ok you guys win, I admit multiple cursors would boost the productivity given by macros

The crowd cheers in excitement

[kapral18]

@tarruda @moljac024 One more thing about multiple cursors not yet reviewed in here but critically important, for example you have some chunk of code and you seek for some literal there and you start by CTRL-N (for example) and seek next occurence of the word and place the additional caret on its start (or better where you cursor in prev word was positioned) and then suddenly you decide to skip several occurences and then continue checking the others. THats the point of all the multicursors besides the things that were already discussed earlier, and this kinda things are absolutely hard to implement with macros on the fly. I dont also get into the account some hard regexp selections that are concerned to exist for detecting some complex multiple cursor behaviour.

[adelarsq]

I see that multiple cursors mode would be something like a visual block editing extension.

[justinmk]

I wouldn't need this feature at all if :%s and friends would update the buffer in real-time

@thiderman @simendsjo Prepare to be amazed: https://github.com/osyo-manga/vim-over works really well, and I believe it recently added support for :%g also. But it is probably a feature worth implementing in the neovim core at some point.

[simendsjo]

@justinmk Cool. Too bad I don't speak Japanese..

[Olivia5k]

Cool! I'll try it out! Also, I'd rather not think of the hoops that developer had to jump through for that, haha.

[justinmk]

@simendsjo Just set up a map to :OverCommandLine like this:

nnoremap g/r :<c-u>OverCommandLine<cr>%s/
xnoremap g/r :<c-u>OverCommandLine<cr>%s/\%V

[JosephFerano]

Just want to come in and lend my support for this feature. I agree with previous posts about the macro vs MC debate. Macros are great and useful but MCs are better in a lot of situations. The thing to remember is that it's not just a fancy search and replace; it's all about using vim motions. That's what truly made the Sublime implementation so amazing; the fact that you could use them with Vintage mode. That is also why the current vim implementations of MCs aren't good; you can't really use proper motions like diw. Although I get by with the current MC implementation, it's really clunky.

[Ivanca]

Unfortunately since this conversation took place (7 months ago) tarruda has made no mention of the feature in the change-logs or in the road-map or any other way so its probably not getting the attention it needs. Such a big change requires a mentality shift not only in the creator of the project but in the community, because things such as the plugin API need to be multiple-caret-aware, so if is not in the core from the beginning it just becomes a big mess to implement it later on.

So far the most promising alternative is limetext.org, an open-source alternative to sublime, but it's still in very early development stages.

[JosephFerano]

@Ivanca

Yes, this is a fair point. Which is also the issue with the emacs implementation of MCs and evil mode. Part of what makes Sublime successful in that regard is that it forced developers to have to be multi-caret-aware as well as having a vim emulation that handles MCs fairly well. While I admit I'm completely ignorant as to how vim works, it still seems to me like it would ultimately be a better alternative to do it natively. That way, if neovim would be binded to sublime or even limetext, at least neovim would be multi-caret-aware and integrate better with those editors.

For me, neovim's true potentially is the ability to allow other editors to bind it and not have to worry about supporting all the vim features. From an opportunity costs stand point, this is going to be huge for the development community accross all languages/editors. Think about it... how many text editors out there have vi emulation layers? How many hours of programming have been spent on something neovim can easily solve? If neovim could have MC support, then more editors will have no issues replacing their emulation layer.

[justinmk]

It doesn't make any sense to work on this feature until other tasks are finished. That's why it isn't getting attention.

[JosephFerano]

@justinmk Thanks for the response! I'm definitely not trying to say you guys should drop everything you're doing right now. I am really impressed with the progress of this project thus far. I was just wanting to add a vote, so to speak, for this feature, and I am willing to donate as well if it'll help. Naturally, when the time is right.