Community
Participate
Working Groups
Steps to reproduce * On a random file, create a block selection * edit stuff ** Expected: multiple carets/selections ** Got: mulitple carets/selections 👍 * Ctrl+Z/Undo ** Expected: edit undone, multiple carets retained ** Got: edit undone, only 1 caret on last line 👎 Same thing seems to happen for most Text operations, like "Line Start", "Line End" who totally ignore block/multi selection.
(In reply to Mickael Istria from comment #0) > Steps to reproduce > * On a random file, create a block selection > * edit stuff > ** Expected: multiple carets/selections > ** Got: mulitple carets/selections 👍 Mickael, I can't understand what the problem is. May be a screenshot could help?
Maybe related or even duplicate: https://bugs.eclipse.org/bugs/show_bug.cgi?id=574942
(In reply to Dirk Steinkamp from comment #2) > Maybe related or even duplicate: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=574942 Copy/paste error ;-) ... I can't remember what I wanted to reference :-/ now. (In reply to Andrey Loskutov from comment #1) > > Mickael, I can't understand what the problem is. May be a screenshot could > help? I tried it out, and it's as described in Mickael's last step: the undo works, but the multi-selection/block selection is gone and reduced to only the last match/row.
List of some other text editing/selection commands that don't respect the multi selection either and mostly reset it to a single selection: - Select next word: Ctrl+Shift+Right - Select previous word: Ctrl+Shift+Left - Select next element: Alt+Shift+Left - Select previous element: Alt+Shift+Right - Delete next word: Ctrl+Del - Delete previous word: Ctrl+Backspace - Delete to end of line: Ctrl+Shift+Del - Delete to beginning of line: no default shortcut Maybe out of scope: - Select enclosing element: Alt+Shift+Up - Restore last selection: Alt+Shift+Down
I did some more digging into the code, and realized there are (at least) two implementations that need to be considered: StyledText and JavaEditor. While StyledText tries to honor multiple carets (but sometimes behaves in an "interesting" way), JavaEditor doesn't seem to be aware of multiple carets (but of block selection!). An approach to remedy this might be twofold: - StyledText: provide some kind of basic "backwards compatible" implementation that maps the single caret handling to implicit multi caret handling, namely in StyledText.setCaretOffset(), possibly other methods, too. I did some first experiments, and simply calculating the delta of the offset and applying it to all other carets would do the trick. I'd say it would be worth a try to assume that any call to setCaretOffset() is an expression of an application that is not multi-caret-aware and thus could get automatic mapping to the other carets. - JavaEditor: make JavaEditor aware of multiple carets, and implement support accordingly. Probably there are other classes similar to JavaEditor that would need a similar "treatment".
(In reply to Dirk Steinkamp from comment #5) > An approach to remedy this might be twofold: > - StyledText: provide some kind of basic "backwards compatible" > implementation that maps the single caret handling to implicit multi caret > handling, namely in StyledText.setCaretOffset(), possibly other methods, > too. I did some first experiments, and simply calculating the delta of the > offset and applying it to all other carets would do the trick. > I'd say it would be worth a try to assume that any call to setCaretOffset() > is an expression of an application that is not multi-caret-aware and thus > could get automatic mapping to the other carets. That's the part that can be covered by this bug. > - JavaEditor: make JavaEditor aware of multiple carets, and implement > support accordingly. Enhancment to Java overridden by Java editor need to be reported to JDT.
(In reply to Mickael Istria from comment #6) > (In reply to Dirk Steinkamp from comment #5) > > An approach to remedy this might be twofold: > > - StyledText: provide some kind of basic "backwards compatible" > > implementation that maps the single caret handling to implicit multi caret > > handling, namely in StyledText.setCaretOffset(), possibly other methods, > > too. I did some first experiments, and simply calculating the delta of the > > offset and applying it to all other carets would do the trick. > > I'd say it would be worth a try to assume that any call to setCaretOffset() > > is an expression of an application that is not multi-caret-aware and thus > > could get automatic mapping to the other carets. > > That's the part that can be covered by this bug. I'll provide a Gerrit patchset for this. Yet this actually doesn't do the trick for the originally reported undo issue. The deselection with the undo actually happens in TextViewerUndoManager - the DocumentUndoListener intents to reveal the change, calling selectAndReveal which only takes a single selection as parameter. With multiple carets this resets the whole thing to a single caret. Two options: 1. don't call selectAndReveal when multiple carets are active -- this seems to work well enough, as it's questionable which caret(s) should be revealed out of the multitude of carets ;-). 2. Rework the DocumentUndoEvent to not only store a single text and offset, but a multitude of texts and offsets. While the 2nd option seems desirable in the long run it's also more effort, needs more understanding of Eclipse than I possess, and probably needs some good planning for the interface StyledText has to expose to support that option. E.g. StyledText doesn't expose the method setCaretOffsets() publicly, which would be needed for selectAndReveal. Besides that the DocumentUndoEvent only seems to store partial information about the undo, namely the preservedText of the last selection. Or there must be several events?!? What does the event type COMPOUND mean? So I will provide 2nd patchset for the 1st option at the moment, and that could probably be reworked later on by someone with more insight into Eclipse.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/191797
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/191798
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/191798 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=579ca5b681fe05936c8272af9109c79c4e4fb1a0
(In reply to Mickael Istria from comment #6) > > - JavaEditor: make JavaEditor aware of multiple carets, and implement > > support accordingly. > > Enhancment to Java overridden by Java editor need to be reported to JDT. https://bugs.eclipse.org/bugs/show_bug.cgi?id=579270
