SCI_SETSELECTIONNSTART sets the selection anchor, instead of the selection start. Similarly, SCI_SETSELECTIONNEND sets the selection caret, instead of the selection end.
This can be seen in Editor.cxx:
case Message::SetSelectionNStart:
sel.Range(wParam).anchor.SetPosition(lParam);
break;
case Message::SetSelectionNEnd:
sel.Range(wParam).caret.SetPosition(lParam);
break;
Contrast this with SCI_GETSELECTIONNSTART and END, which correctly get the start and end:
case Message::GetSelectionNStart:
return sel.Range(wParam).Start().Position();
// ...
case Message::GetSelectionNEnd:
return sel.Range(wParam).End().Position();
This issue does not describe the desired solution.
Please specify the behaviour you want completely.
The main justification for these calls is symmetry - there are
GetSelectionNStartandGetSelectionNEndcalls so adding the 'set' calls makes it simpler for applications to treat them as properties.Hi Neil
The desired solution is that SCI_SETSELECTIONNSTART sets the selection start point, as the function name implies. Same for SCI_SETSELECTIONNEND. Currently they set the anchor and caret respectively, which is a problem as the anchor isn't always at the start and the caret isn't always at the end.
Exactly - the issue is that they currently aren't symmetric. In other words, the Set call does not modify the property that the Get call retrieves.
When I said "specify ... completely" I meant "completely", not just restating the title.
Specify the algorithm you want. In detail.
If you don't know how to write out an algorithm, examine each possible situation and say what the result should be.
For example, if caretN=1,anchorN=2 what should be the resulting caret and anchor after SCI_SETSELECTIONNSTART(N,3)? If both caret and anchor are 2, what should the results of SCI_SETSELECTIONNSTART(N,3) be? Work through all the possible configurations and see if it produces a coherent design.
I don't have much Scintilla experience, but there are a few options I see
One is to make them behave just like the singular SetSelectionStart/End functions, for consistency. However, I don't like the assumption they make "that the anchor position is less than the current position."
My intuition for the behaviour of setting the start position is this:
This satisfies the property that the selection start is now at the specified location, while doing what I think is the obvious thing when setting past the end, which is to "push the end forward" with it.
The equivalent idea could apply for setting the end, but it would default to moving the caret, not anchor, if empty.
I think this is coherent? If the intent of your question is to help me understand why a coherent design couldn't exist, I think it would be better if those functions were deprecated or something.
Regardless of any changes, I also think that it would be great to improve the documentation of the current behaviour of SetSelectionNStart/End, since they don't currently do what they say they do.
Could you use SCI_SETSELECTIONNCARET & SCI_SETSELECTIONNANCHOR when you want to control which pos is the caret and which is the anchor? In scintilla, the start of selection is merely the min of the anchor & the caret and the end of the selection is the max. Note that this differs from other editor implementations (each does things a bit differently when you get into the details)
Committed an implementation as [ac6a2d].
Related
Commit: [ac6a2d]