Cursor multi-select pastes multiple copies multiple times instead of one copy multiple times
This is very bizarre behavior for a multi-cursor feature. When I paste across multiple cursors, I expect one paste copied multiple times. Instead, I get multiple copies multiplied by the number of cursors I have.
See here for a demonstration:
https://youtu.be/rCqceurvXI8
I am adding a selection of text to the clipboard with Ctrl-X. Then I made multiple selections to where I want to paste it with Ctrl-V. Instead of one copy pasted at each selection/cursor, the number of copies multiplies times the number of cursors. This is very bizarre and unexpected.
Incidentally I do see this issue if I either:
- Use ALT-click to place multiple cursors, or
- Use the new Ctrl+F Find overlay (new in 4.33) to select multiple matches
I do not see the issue if I make a rectangular selection. But the only way I know how to do this is to go into Block Selection mode (Alt+Shift+A). I'm curious how you reproduced this video? Did you assign a custom keyboard shortcut to create multiple cursors?
Use the new Ctrl+F Find overlay (new in 4.33) to select multiple matches
FWIW, you don't particularly need the new find dialog, the older one has had "Select All" that can do it too.
Use the new Ctrl+F Find overlay (new in 4.33) to select multiple matches
There are some shortcuts already assigned. In Preferences > General > Keys, search for "caret" and you'll see them.
the older one has had "Select All" that can do it too.
Ah yes, so it can. Yes, now you mention I remember that coming in and making the dialog bigger - but guess I never used it. Strange how a visual change can change the way you expect to do something...
There are some shortcuts already assigned. In Preferences > General > Keys, search for "caret" and you'll see them.
Thanks found them, although in Eclipse SDK (at least) these appear to be unbound.
I encounter this issue using the keybinds for
-
Multi selection up relative to anchor selection -
Multi selection down relative to anchor selection
Version: 2024-06 (4.32.0)
Build id: 20240606-1231
Additional information
There are several variables to consider when pasting text:
- Clipboard content (source)
- single line
- multiple lines
- Selection (target)
- single range
- multiple ranges
- block
The code responsible for pasting does not account for all the possible combinations.
In this issue we are talking about
source = single line
target = multiple ranges
which leads to toInsert being filled with multiple copies of our source by for (int i= 0; i < lines - 1; i++) {.
However, we probably only want multiple copies of the source when source = single line, target = block (that is at least the current behaviour).
IMO solving the whole ordeal cleanly requires to first agree on a default behaviour for each of the possible combinations. Though at bare minimum the behaviour should stay as it is for the good cases and get additional handling for when the target is not a block but multiple ranges.
A contribution attempting to fix this would be welcome as a pull request ;)
What exactly are you after in a pull request? (serious question)
I can share the modifications I would apply, i.e. String toInsert = contents. That`s it. This covers my workflows of only using multi-ranges and no blocks. Though sharing that is basically at odds with other eclipse platform consumers who depend on the block-pasting being supported and it also doesn't cover all features. I think I did my duty by digging deeper and giving my analysis of the situation. I doubt that "solution" is what you are looking for.
Properly resolving the whole situation is basically the effort of a full-time job, ideally by someone who balances the interests of the diverse clientele.
What exactly are you after in a pull request? (serious question)
A change in the code that fixes the issue.
I can share the modifications I would apply, i.e. String toInsert = contents. That`s it. This covers my workflows of only using multi-ranges and no blocks. Though sharing that is basically at odds with other eclipse platform consumers who depend on the block-pasting being supported and it also doesn't cover all features. I think I did my duty by digging deeper and giving my analysis of the situation. I doubt that "solution" is what you are looking for.
Indeed, we cannot accept changes that would break established use-cases.
Properly resolving the whole situation is basically the effort of a full-time job, ideally by someone who balances the interests of the diverse clientele.
No-one has shown up so far with such profile and such interest. People who suffer from the bugs are usually more interested in getting them fixed. If you, or anyone else, are willing to give a try to a complete solution one day (which I'm not sure is so much more difficult, it's mostly a matter of combining the right if (...)), you'll still be welcome.