#1992 SciTE: Stripping trailing spaces moves the caret.

[Van de Bugger]

SciTE 3.7.5 (on Linux x86_64, buty it should not matter).

If strip.trailing.spaces is true, saving a file strips trailing spaces. It is a desired action, but with a side effect: saving the file may move the caret (if the caret was at (or behind) the end of a line with some trailing spaces). It is not a big deal if you save the file, but it is extremely annoying if any form of autosaving (either save.on.timer or save.on.deactivate) is turned on: from time to time the editor sabotages your work by deleting spaces you just typed!

If virtual space is enabled, such editor misbehaviour can be fixed gracefully: let editor strip trailing spaces, but force it to keep the caret location intact.

[Neil Hodgson]

There are some minor style convention issues.

Member functions in SciTE are always PascalCase - initial capital.

The name "Selections" sounds like a passive container of selections. Since the point of this is to restore selections, the name should reflect that role.

There is a narrowing conversion in 64-bit builds due to size() returning 64-bits and int being 32-bits with

n = selections.size()

Avoid the warning with a cast. It's simpler to drop the extra 'n' variable - its not a win for performance.

The constructor should be "explicit" to prevent the possibility of implicit conversions.

Simple conversion functions use 'from' instead of 'to' so that the source goes next to the argument and the return next to the receiver. So

JobSubsystem SubsystemFromChar(char c);
jobType = SubsystemFromChar(subsystemVal[0]);
std::vector<int> LinesFromString(const std::string &s);

Comments are excessive and should just state the functionality in a positive manner. Arguments for a change go on this tracker.

[Van de Bugger]

1. Case of member functions fixed.
2. Selections renamed to SelectionKeeper. If you do not like this name please be more specific and let me know exact name.
3. Dropping n and using directly selections.size() causes warning "signed/unsigned comparison". Range loop used to avoid warnings.
4. Constructor made explicit.
5. Conversions renamed to PosFromLoc and LocFromPos.
6. Comment cut.

[Neil Hodgson]

OK, committed as [0f423b] with formatting normalized by running it through astyle.

[Juan Carlos Arevalo-Baeza]

I was actually relying on the old behavior quite often. It was very useful to get a multiple cursor at the end of a group of lines, to append to all of them simultaneously.

I can still almost sort-of get that old behavior by disabling virtual space. Unfortunately, block selection past the end of the lines when virtual space is off is awkward. The second corner ends up at the end of the text of the line where the cursor is, so if the last line of the block is short, a lot of text gets selected in the intervening lines, even if it's in the opposite direction of where the box was drawn. I can still get what I wanted by first padding thefirst and last lines to match (or exceed) the longest line in the block, and then do the block selection, and save (stripping spaces). Awkward.

Having non-virtual-space block selection select just text that is under the box drawn by the cursor would arguably be better. The question then is what to do with the lines that don't quite reach the cursor-drawn box. They could get a cursor at the end of every such line, wherever that end is, or they could get no cursor (so we'd get multiple blocks in a selection, for all lines which intersect the box). SciTE already almost does the former (except for the effective positioning of the corner of the box). I'd favor the former, as it'd help me with the workflow I was talking about above, but the latter is arguably more consistent with the user actions. That seems ripe for a setting.

I hope this was not too confusing. I might try to contribute this, but I'd appreciate thoughts.

[Neil Hodgson]

Reverting this fix is not a good approach as the technique discussed is difficult to discover so unlikely to be widely used.

Selecting the line ends of a range is a useful operation but the best way of achieving it is uncertain.

One possibility is to add a way to convert from a rectangular selection to a multiple selection. Then press the End key to move each part of the multiple selection to the line ends.

This topic would probebaly see more input on the mailing list than on a closed bug report.