-
-
Notifications
You must be signed in to change notification settings - Fork 54
Description
Is there an existing request for this?
None that I know of.
- I have searched the existing issues
Is your feature request related to a problem?
Yes, it is:
If you actually prefer editor_cursor_beyond_eol=false for good, frequent use of column selection brings about so awkward situations you likely find yourself wishing to flip it to true as a relief - for the single purpose of allowing to mark rectangles by natural, straight moves, because with false (as of mcedit v4.8.33), quick column selection is hampered by any shorter lines.
To mark a rectangular region, you can generally proceed in four directions:
- from upper left to lower right corner
- from upper right to lower left corner
- from lower right to upper left corner
- from lower left to upper right corner.
If the top or the bottom line (let alone both) is shorter than the longest to-be-selected line, you need to engage in funny maneuvers, like
- moving the cursor to one of the other corners first, so you can then start marking the rectangle in the "right" direction (i. e. one that works, if any), or
- temporarily appending auxiliary spaces at the end of shorter lines, so you can move the cursor far enough to the right while selecting.
Describe the solution you'd like
When in column selection mode, generally allow the cursor to move (horizontally or vertically) beyond EOL, as if "cursor beyond end of line" was enabled.
Describe alternatives you've considered
- (a) enable "cursor beyond end of line" permanently
--> this would entail UX changes/peculiarities the user may not feel comfortable with on a daily basis (when not in column selection mode) - (b) manually enable "cursor beyond end of line" temporarily each time
--> possible, but doing so would be at least as clumsy as the navigation maneuvers currently required. - (c) start selecting from the end of the first or the last line, whichever is longer
--> doesn't handle cases with even longer lines in the middle
--> even where it works, this may involve a great deal of extra cursor movement - (d) add temporary spaces where needed, and remember to remove exactly those spaces from the original when you've finished the copying operation
--> possible, but this is so roundabout it can't seriously be meant to be the way to go
--> also, the addition and removal of actual spaces introduces an additional source of errors.
Additional context
- From a user's perspective, this feature can be regarded as the "input" counterpart to the "output" improvement provided by (the resolution of) editor: skipped trailing spaces in the last short line in the copied/moved column #4894 .
- It might also resolve Column selection failure #1970, although I'm not entirely sure I understand the OP there correctly.