20 comments
Comment actions Permalink

btw, is it necessary to call #com.intellij.openapi.editor.impl.EditorImpl.CaretCursor#repaint  in com.intellij.openapi.editor.impl.EditorImpl.CaretCursor#setPosition?
Because the move of the cursor(s) is much smoother without that, and also eats less cpu - it was clearly visible for me while debugging of IntelliJ (Win 7,  http://twitch.tv/vojtechkrasa/b/487947446 )

0
Comment actions Permalink

So I implemented also multiple selections.
http://twitch.tv/vojtechkrasa/b/488244395


Other than some details to polish, the only thing missing is some blessing that the concept is right :D

0
Comment actions Permalink

Hello, Vojtěch,

Screencasts look promising, thanks for your work.
I'll have a look at the code when I'll start working on this feature.

0
Comment actions Permalink

Awesome work Vojtech, that looks really good! I'm sure there are tons of edge cases to cover but the concept looks great. This is one of the few things I still use Sublime for.

0
Comment actions Permalink

Hello,

Ok, thanks.

And congratulations on your first post :)

0
Comment actions Permalink

Edge cases? Well, not much, all I know about are just live templates and autocomplete, but I think that Sublime disables them when all carets do not have the same text before them, so it could be done too.

But those selections in editor should now behave exactly like in sublime, even the block selection. ;)

0
Comment actions Permalink

So do you disable autocompletion and so forth? What about expand selection and so on, does that work on all cursors?

0
Comment actions Permalink

I have not touched anything on that yet, actually autocompletion do not work at all, those stuff with popups need some fix...  :^O

Expand selection and other actions from the Sublime menu are not implemented, I just did the general stuff, but everything will work. :)

0
Comment actions Permalink

I like the idea of multiple carets, it definitely seems very promising.

With regards to auto-completion, and edge cases in general; Would it be possible to simply cancel the other carets and only use the last placed one? I would imagine this to be an appropriate fallback, and intuitive UX decision?

0
Comment actions Permalink

Actually spawn of auto-completion does not go through multi-caret logic so it just uses normal caret, which on the position of the last placed one. 

I was able to fix it, I just skip all the multi caret logic and execute original code when there is a lookup so it does not get messed up, but the result and everything you type will get placed everywhere (because I wrapped the logic which actually writes into the editor).
It works fine, the bad thing is that I do not see on com.intellij.codeInsight.lookup.LookupManager#getActiveLookup, so I had to hack it through editor UserData to know if there is an auto-completion...

0
Comment actions Permalink

I think my prototype is quite usable, since I implemented expanding selection and Undo support. Afaik only some live and surrounding templates are a little buggy... So if anyone wants to try it out, be my guest.

0
Comment actions Permalink

I've checked the code and played a bit with your implementation. There's one problem with your approach - storing caret positions just as offsets won't always work as expected in presence of folded regions or soft wraps - that's why CaretModelImpl stores, along with other things, a visual caret position. In particular, calling CaretModel.moveToOffset with the argument obtained from CaretModel.getOffset won't necessarily leave the caret position as-is. I've seen this to cause glitches when moving carets through folded regions or soft wraps, potentially there can also be some other edge cases. (Also repeatedly setting CaretModel and SelectionModel offsets when switching between carets/selections generates 'fake' change events, which can have side effects. This problem by itself could have been fixed quite easily though).
So, I believe, it's better to do it in a somewhat different way - implement several 'real' carets inside CaretModelImpl, in the same way a single one is now implemented there, and allow model clients to work with the 'current' caret, which will be iterating over all existing carets in EditorAction and other required places (like in your implementation). I'll start working on a prototype now.

0
Comment actions Permalink

I see, that's right. I will change that the way you said. That should not be a problem.

0
Comment actions Permalink

So I have made the changes, it works nicely (of course it needs some cleanup).

Is source code to your prototype somewhere published?

0
Comment actions Permalink

Not yet. Once it be usable, it will be in master and in the nearest appropriate EAP.

0
Comment actions Permalink

Can Vojtěch Krása not send a PR for his changes to be merged into master perhaps? :)
I believe the only additional work required would be to sign a CLA?

0
Comment actions Permalink

I'm looking at what Vojtěch did and what he is doing (thanks again to him, as it always helps to see some working example, even if I cannot take the implementation as it is), but I'm now working myself on it. Keep calm :) It will be in master ASAP.

0
Comment actions Permalink

Btw, you can take anything you want, I have already signed that CLA.

0
Comment actions Permalink

This is a great feature, that I would love to see being part of IntelliJ IDEA's core. Is your prototype available as a plugin?

0

Please sign in to leave a comment.