Community
Participate
Working Groups
Sublime or VS Code users are really in love of multiple cursors for text edition. The principle is to create other cursors on the lines above of behind with Ctrl+Alt+Up or Ctrl+Alt+Down, or directly another cursor anywhere else with a Ctrl+Clic. Then any text insertion of deletion happens simultaneously on all cursors. This seems pretty useful for repetitive code, such as JSon or CSS.
We could probably reuse the linked mode infrastructure for this.
Just for reference, there is a plugin on GitHub [1] that provides partial multiple cursor support based on linked mode. The main limitation is that you can't really add new cursors, but just find->replace multiple occurrence of the same text string. [1] https://github.com/caspark/eclipse-multicursor
Also, the "toggle block selection mode" allows to cover some (many?) use-cases for the multiple cursor approach. However, it's mouse only, which makes it not so accessible while writing code.
(In reply to Mickael Istria from comment #3) > Also, the "toggle block selection mode" allows to cover some (many?) > use-cases for the multiple cursor approach. However, it's mouse only, which > makes it not so accessible while writing code. No, you can toggle via Atl+Shift+A and select using the keyboard.
(In reply to Dani Megert from comment #4) > No, you can toggle via Atl+Shift+A and select using the keyboard. It took me some time to discover that Shift is the key to use for that. Overall, I believe this feature is already good for several use cases of mutliple cursors. I guess it's a good starting point if someone wants to implement it in a way that wouldn't require cursors to be on the same column.
The block selection mode works quite fine for successive lines, but another use case is to search for occurrences of a string and edit all of them at once (search all, or search next/previous).
(In reply to Vlad Dumitrescu from comment #6) > The block selection mode works quite fine for successive lines, but another > use case is to search for occurrences of a string and edit all of them at > once (search all, or search next/previous). Using Ctrl+F or Ctrl+H dialog enable replacement workflows. What do you think are missing for this user story?
When editing inline, you can get live syntax highlighting, code completion, etc, as well as replacing with a multi-line value, which the search/replace dialog doesn't offer.
*** Bug 511608 has been marked as a duplicate of this bug. ***
An ideal implementation would be to have SWT and underlying libraries to add multiple cursors to the widget, and JFace's viewers and/or Eclipse's TextEditor would "simply" take care of invoking the operation to add/remove cursors.
(In reply to Mickael Istria from comment #10) > An ideal implementation would be to have SWT and underlying libraries to add > multiple cursors to the widget, and JFace's viewers and/or Eclipse's > TextEditor would "simply" take care of invoking the operation to add/remove > cursors. Yes, this will need support from SWT.
I don't see a huge problem to having SWT support multi-carets/cursors, but I'm more curious about the functionality. If given the API to create additional cursors, what will happen if you click somewhere (move the cursor) when you already have multiple cursors? Would it clear every other cursor and just include one in that case?
Yes, that's how it currently works in Sublime & WebStorm. Once you click somewhere else in the code, all the cursors disappear, and you are left with the one you just clicked on.
(In reply to Ian Pun from comment #12) > If given the API to create additional cursors, what will happen if you click > somewhere (move the cursor) when you already have multiple cursors? Would it > clear every other cursor and just include one in that case? Right, and some other action (click+modifier or right-click > "add cursor here" for instance) could be used to place an additional cursor.
*** Bug 522093 has been marked as a duplicate of this bug. ***
I've seen a demo about a user of multi-carets/multi-selections in VSCode yesterday and learnt about some realistic use-cases and got some feedback about potential implementation: There are 2 main ways to use multi-carets/selection * Either starts from one or several block selection to select successive lines at the same column * Or user builds a multi-selection of the same word. The is basically a shortcut "also select next/all instance of currently selected word". * Does *NOT* really care about mouse based multi-selection which seems to be a less important case. Modifyig (expanding/shrinking) multi-selection happens in the context of the line, so operation like * select to line start/end * Select next word will select the result applied to each selection so if I have """ blah |foo bar kikoo |lol """ where | are carets, then "foo" and "lol" are selected. It looks like the Block Selection mainly reads the 1st line to apply the selection modification to all lines. Once the multi-carets/multi-selections are enabled, they're used to * Delete/insert text at multiple location (block selection already does that) * Change case or apply some bulk operation such as formatting. I think it's affordable and that any usage of StyledText that takes care of honouring the StyledText.getSelectionRanges() *plural* method should work well with multi-carets/multi-selection, since from contumer perspective, there is no big difference between a block selection and a multi-selection when using this method. Now, about a proposal: Make block selection is a special case of multi-selection and multi-selection a general case of block-selection; that means introduce more general methods for *plural* setSelectionRanges(,,,) and make the method about block selection rely on those as much as possible and start using this new API in place of the block selection one. Maybe even deprecating the block selection specific methods.
Created attachment 277918 [details] Example 1
IBlockTextSelection already has an extremely interesting "getRanges()" method. This method could probably be extracted in a super IMultiTextSelection interface that -unless it's a IBlockTextSelection- can represent the multi-selection model. The internal SelectionProcessor.getRanges() needs to be provided an extra "Implementation" for the new model. With this, basic operations like delete, change case and so on should work; the only remaining tricky ones are copy/paste. Overall, it seems like it's now relatively easy to get started and draft a good 1st iteration.
New Gerrit change created: https://git.eclipse.org/r/153689
Hi @Mickael. I saw you provide a draft. Do you need some feedback from user perspective. If so how should I try your patch ?
(In reply to Gautier de SAINT MARTIN LACAZE from comment #20) > Hi @Mickael. I saw you provide a draft. Do you need some feedback from user > perspective. > > If so how should I try your patch ? It doesn't even compile. I've submitted it because I've got a bunch of patches inprogress for platform.text and didn't want to lose my current progress; and also to get some curious people looking at it if they're interested. But there is nothing to test yet. When I have something working-ish for this 1st iteration, I'll post a video. This will be a multi-steps change anyway: 1st is enabling the editon (that's what the patch tries to do), then editor feedback (draw multiple selections), then dealing with selection change (arrows, Shift+arrows), then with copy-paste and other stuff that's beyond plain edition, then about how we make multi-caret usable to user via shortcuts, right-click or search dialog...
New Gerrit change created: https://git.eclipse.org/r/154419
Created attachment 281223 [details] VSCode demo with MirrorCursorOnMatchingTag on HTML VSCode (Insider) provides a very cool feature for auto rename tags with their HTML Language Server. We are doing that for LSP4XML (XML Language Server) and I will love if we could have this same feature inside Eclipse IDE. See attached demo.
(In reply to Angelo ZERR from comment #23) > Created attachment 281223 [details] > VSCode demo with MirrorCursorOnMatchingTag on HTML > > VSCode (Insider) provides a very cool feature for auto rename tags with > their HTML Language Server. We are doing that for LSP4XML (XML Language > Server) and I will love if we could have this same feature inside Eclipse > IDE. See attached demo. The LinkedEdit can already handle that use-case.
Created attachment 281280 [details] Demo of work in progress I attached a video demo of the current progress (with the patches attached here). I find it pretty encouraging, most of the work now is fixing some glitches like: * missing drawing of extra carets for StyledText (in SWT) * fix color of the selection when multiple selection are on the same lime (in SWT) When this part is done in SWT, I think we can consider a merge. Then in JFace/Editors * Fix some selection computation so caret doesn't move erroneously * Fix some operations so the selection isn't overriden * Allow editors to take as input the IMultipleTextSelection (could be the cause of the previous item) And after, in the IDE at large: * Make this feature accessible ** probably from the "Find/Replace" dialog first ** maybe with a new context menu entry in the "Edit" group
Looks very promising so far, good work!
(In reply to Mickael Istria from comment #25) > Created attachment 281280 [details] > Demo of work in progress Very nice! Would be great if you could add the blocking issues to this one.
Created attachment 281411 [details] Newer demo of work in progress
Thank you, Mickael, for your efforts with this! Eager to try it out!
For reference when we are considering the "workflow" part of this issue, here is a 3rd party tweet documenting the main multi-cursors operation in Sublime: https://twitter.com/mildmojo/status/1216602234143809536
I've removed the 'plan' keyword because no target milestone was set. A plan bug must always have a target milestone. If you consider to set the 'plan' keyword again, make sure that the target milestone must match the release where it was originally planned. If the work was not finished, a follow-up plan bug for the next release must be created and the old one left in the NEW state. Not doing so would destroy the initial plan. The plan must reflect what has been delivered and what not. Also, please make sure that you only tag root/top-level bugs with 'plan'. Bug fixes or simple things must not get the 'plan keyword.
Adding multi-carets to SWT StyledText (and remaining issues/subtasks before it can actually be merged) is now discussed in bug 562676. This bug can remain open for later, when bug 562676 and we want to consume it in JFace/Editors/IDEs, but it's not where most of the work is likely to happen soon, nor where it should actually happen as long a bug 562676 is not fixed.
(In reply to Mickael Istria from comment #32) > Adding multi-carets to SWT StyledText (and remaining issues/subtasks before > it can actually be merged) is now discussed in bug 562676. > This bug can remain open for later, when bug 562676 and we want to consume > it in JFace/Editors/IDEs, but it's not where most of the work is likely to > happen soon, nor where it should actually happen as long a bug 562676 is not > fixed. +1.
Is it really nescessary to wait for multiple cursors in SWT? When I'm using "Ctrl-2 R" I can already edit occurrences of the same identifier in various places -- they get surrounded by a box. Maybe that's a different concept, but in practice I'd be very happy to be able to edit the same text in various places regardless weather they are identifiers or simply same text. But maybe I'm mixing two topics here, that should not be mixed.
I'm going to update the patch to support multi-selections in JFace and text editors. Here is what I'm thinking about a few ways to enable it in editors: 1. Add a new "Add caret at mouse position command" (benefit is that it's opt-in and would only appear on Ctrl+3 so it wouldn't cause issue by inadvertance) 2. Moving back from BlockSelection to retain selection but as a multi selection. Issue is that some people will not be expecting that (but I guess they won't really complain), and that will trigger multi-selection to many users in some standard workflow => maybe too early to have this? 3. a "Select All" in the Find dialog => same issue as above, isn't it too early to promote this in such a common place? What do you think we should implement for this release?
1 would be OK. 2 probably not. 3 not sure how that would be used. In all that, I miss a *good* use case where one would intuitively expect multiple carets to appear. The use case shown in editing html tags is very markup languages specific, and probably should be addressed in webtools, not in the platform/jface, and doesn't require multiple carets actually. Search / multi-edit in the file is *the* candidate, but Java editor does that already via "rename in file" - and generalization of this use case could be possible for all "connected regions" - but again, no need here for multiple carets at all, the way it works doesn't require to show multiple carets. Don't get me wrong, but it looks like we re-invent the wheel here.
@Andrey: see comment #16 where I try to explain a user story of a user building from a SQL file a new .java with dozens of fields with ORM mapping annotations by using multi-selection to insert prefix, change cases of words, copy-paste on several lines, and basically focusing on a single edition chain that actually applies to dozens of lines. I used to be skeptical about multi-carets/selections, but since I've seen this demo, I really think they can be a powerful tool for batch operation on some boilerplate code usually captured in very "uniform" files. Concretely, they can be used to replace regexps in many cases, with a more fault-tolerant, faster and incremental feedback.
@Mickael I agree! I've seen some demonstrations and it seems to be very useful in certain scenarios. Here's some use cases: https://youtu.be/v3i5aTw5je4?t=1837 -- I'd suggest watching it till 34:30. ALT-J made Victor switch from eclipse to IntelliJ (after 13 years) -- maybe it's possible to win him back ;-) ...
As a user of Eclipse IDE, Intellij IDEA and VS Code, I miss multiple carets/cursors/selections in Eclipse IDE. It's the main reason I don't use WWD but VS Code instead of Eclipse IDE for web development. I also miss the feature when I refactor some Java code.
Created attachment 286815 [details] Demo with current patch set Here is a new demo, using current patchset, showing a more concrete use-case for such feature. I shows that things are working already in many ways; it also shows some glitches, mostly caused by the fact that many/most text operation are not capable of handling multiple (or even block) selection yet. This is the topic of bug 574942
Created attachment 286906 [details] Newer demo, with multi copy/paste
Really impressive. I can't wait for release :). Do you need some testing from end users?
(In reply to Gautier de SAINT MARTIN LACAZE from comment #42) > Really impressive. I can't wait for release :). > Do you need some testing from end users? There are still a few things I'd like to improve before more widely asking for feedback. But if you're really willing to give it a try now, there is no reason to prevent you from doing it ;)
https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/153689/ is ready for review. The important part to look at is the new interfaces & types for TextSelection. Apart from that, the code adds no new API. To use it, you can trigger a block selection; and then invoke the "To multi-selection" command (available in the Edit menu and in Ctrl+3. Then the multi-selection should turn on and you'll be able to reproduce the demos and try more. Note that this is currently an action that is only available when triggered manually with a new command, so all legacy workflows are expected to remain unmodified.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/153689 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=bf5933129b8eb15b5b7cdefa781eacc1c4a5e3b9
Done.
(In reply to Mickael Istria from comment #46) > Done. Brilliant. This was a great bug to follow. Thank you for your persistence.
(In reply to Mickael Istria from comment #46) > Done. Thank you for your hard work on this! Demos look really nice! Really looking forward to having this in Eclipse!
(In reply to Eclipse Genie from comment #45) > Gerrit change > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/153689 was > merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/ > ?id=bf5933129b8eb15b5b7cdefa781eacc1c4a5e3b9 Reopening, this breaks Java console, see bug 575872.
(In reply to Andrey Loskutov from comment #49) > (In reply to Eclipse Genie from comment #45) > > Gerrit change > > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/153689 was > > merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/ > > ?id=bf5933129b8eb15b5b7cdefa781eacc1c4a5e3b9 > > Reopening, this breaks Java console, see bug 575872. Any advantage of reopening this bug Andrey? Blocking shows the relationship clearly and fix will go in 575872.
(In reply to Sarika Sinha from comment #50) > (In reply to Andrey Loskutov from comment #49) > > (In reply to Eclipse Genie from comment #45) > > > Gerrit change > > > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/153689 was > > > merged to [master]. > > > Commit: > > > http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/ > > > ?id=bf5933129b8eb15b5b7cdefa781eacc1c4a5e3b9 > > > > Reopening, this breaks Java console, see bug 575872. > > Any advantage of reopening this bug Andrey? > Blocking shows the relationship clearly and fix will go in 575872. Yes. The "resolved fixed" means, there is no work to do anymore on the bug. Obviously, this is not the case => reopening.
(In reply to Andrey Loskutov from comment #51) > > Yes. The "resolved fixed" means, there is no work to do anymore on the bug. > Obviously, this is not the case => reopening. If it spans our multiple releases, retargeting spoils the Project Plan. Opening the resolved bug from previous release makes it difficult to understand when was the main feature released.
(In reply to Sarika Sinha from comment #52) > (In reply to Andrey Loskutov from comment #51) > > > > Yes. The "resolved fixed" means, there is no work to do anymore on the bug. > > Obviously, this is not the case => reopening. > > If it spans our multiple releases, retargeting spoils the Project Plan. > Opening the resolved bug from previous release makes it difficult to > understand when was the main feature released. The bug was targeted 4.22 M1.
Oh! Looks like Michael chose 4.22 M1 instead of 4.21 M1 ? @Michael! Please confirm.
(In reply to Sarika Sinha from comment #54) > Oh! Looks like Michael chose 4.22 M1 instead of 4.21 M1 ? > @Michael! > Please confirm. Sorry for spamming! I got confused with Bug 562676.
Created attachment 287109 [details] Screencast
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/185191
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/185191 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=a3afb05623cbea55dfe6836ca57afa7620072c5b
(In reply to Eclipse Genie from comment #45) > Gerrit change > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/153689 was > merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/ > ?id=bf5933129b8eb15b5b7cdefa781eacc1c4a5e3b9 This also breaks JDT, see bug 575520 => reopening.
(In reply to Andrey Loskutov from comment #59) > (In reply to Eclipse Genie from comment #45) > > Gerrit change > > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/153689 was > > merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/ > > ?id=bf5933129b8eb15b5b7cdefa781eacc1c4a5e3b9 > > This also breaks JDT, see bug 575520 => reopening. This also breaks text selection in editors => bug 575900.
Also breaks XML editor closing, see bug 575909.
Also breaks navigation in all text editors, see bug 575942 - "Home" & "Line end" don't work anymore in text editors
All known regressions should be fixed now.
Created attachment 287218 [details] More complete demo with current SDK
(In reply to Mickael Istria from comment #64) > Created attachment 287218 [details] > More complete demo with current SDK Thank you for creating this. Very nice.
Thanks for putting all the effort into this - it looks great already! Question/Suggestion: Would it be possible to have something like ATL-J in a well known other Java-IDE ;-) ... meaning: take the current selection and add another selection that matches the currently selected text? I can't find anything of the likes in the most recent demo, and also not in the preliminary release notes for 4.22. Example: Given the code: public static final String a; public static final String b; public static final String c; When: - Selecting the first "public" (line a) - pressing ALT-J Then: - the next found "public" gets added as a multi-selection (line b, when pressing again line c) Variations: - ALT-SHIFT-J removes the last added selection from the multiselection - when invoked without a selection, the selection is automatically expanded to the currently selected (sub)word and this selection is then taken for multiselect - ALT-SHIFT-J when only the original first selection area exists could add a new multiselection with a match *above* the original selection - CTRL-ALT-SHIFT-J to select all matching occurrences Here's an example of the basic functioning: https://www.facebook.com/watch/?v=1442031062486810 Thanks for considering! :-)
(In reply to Dirk Steinkamp from comment #66) > Question/Suggestion: Would it be possible to have something like ATL-J in a > well known other Java-IDE ;-) ... meaning: take the current selection and > add another selection that matches the currently selected text? Pldzxd open a new ticket dedicated to this request.
(In reply to Mickael Istria from comment #67) > Pldzxd I not so clearly meant "Please". Another approach to achieve what you want is to * Select the part of the document you're interested in * Ctrl+F, seach for `public` in "Selected lines" * "Select All" * Left
I got that ;-) ... Thanks, I read your reply that such features are not supported yet, and thus I'll open a new ticket. :-)
The new ticket is this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=576377
