[scintilla:bugs] #2488 SCI_SETSELECTIONNSTART and END set anchor and caret instead

[Tom Mewett]

---

[bugs:#2488] SCI_SETSELECTIONNSTART and END set anchor and caret instead

Status: open
Group: Bug
Labels: scintilla
Created: Sat Sep 27, 2025 04:06 PM UTC by Tom Mewett
Last Updated: Sat Sep 27, 2025 04:06 PM UTC
Owner: nobody

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();

---

Sent from sourceforge.net because scintill...@googlegroups.com is subscribed to https://sourceforge.net/p/scintilla/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/scintilla/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Neil Hodgson]

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 GetSelectionNStart and GetSelectionNEnd calls so adding the 'set' calls makes it simpler for applications to treat them as properties.

[Tom Mewett]

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.

The main justification for these calls is symmetry

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.

---

[bugs:#2488] SCI_SETSELECTIONNSTART and END set anchor and caret instead

Status: open
Group: Bug
Labels: scintilla
Created: Sat Sep 27, 2025 04:06 PM UTC by Tom Mewett

Last Updated: Sat Sep 27, 2025 10:31 PM UTC
Owner: nobody

[Neil Hodgson]

The desired solution is that SCI_SETSELECTIONNSTART sets the selection start point

When I said "specify ... completely" I meant "completely", not just restating the title.

Specify the algorithm you want. In detail.

---

[bugs:#2488] SCI_SETSELECTIONNSTART and END set anchor and caret instead

Status: open
Group: Bug
Labels: scintilla
Created: Sat Sep 27, 2025 04:06 PM UTC by Tom Mewett

Last Updated: Sun Sep 28, 2025 11:30 AM UTC
Owner: nobody

[Neil Hodgson]

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.

---

[bugs:#2488] SCI_SETSELECTIONNSTART and END set anchor and caret instead

Status: open
Group: Bug
Labels: scintilla
Created: Sat Sep 27, 2025 04:06 PM UTC by Tom Mewett

Last Updated: Sun Sep 28, 2025 10:24 PM UTC
Owner: nobody

[Tom Mewett]

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:

1. Pick the side (caret or anchor) of the selection is currently at the start of the selection, defaulting to the anchor if the selection is empty.
2. Move this side to the specified position.
3. If this has moved that side to now be after the other side of the selection, also move that side to the specified position.

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.

---

[bugs:#2488] SCI_SETSELECTIONNSTART and END set anchor and caret instead

Status: open
Group: Bug
Labels: scintilla
Created: Sat Sep 27, 2025 04:06 PM UTC by Tom Mewett

Last Updated: Sat Oct 11, 2025 08:36 PM UTC
Owner: nobody

[John Ehresman]

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)

---

[bugs:#2488] SCI_SETSELECTIONNSTART and END set anchor and caret instead

Status: open
Group: Bug
Labels: scintilla
Created: Sat Sep 27, 2025 04:06 PM UTC by Tom Mewett

Last Updated: Sat Oct 18, 2025 06:19 PM UTC
Owner: nobody