How to determine if a selection is in progress?

[seasoned_geek]

All,

This should be fall off a log simple, but the doc isn't clear and my first interpretation appears to be incorrect.

Because there is navigation going on that isn't controlled by the ScintillaEdit widget under C++, I have need of determining if a selection is currently happening or not so I can call normal move functions or their Extend() versions. I was using selectionStart() under the false assumption it would only have a value > -1 when a selection was in progress. Turns out selectionStart() always returns the current carret position.

Please tell me the widget doesn't rely on an anchor and carret being different like far too many PC based designs. I had to dance around that with the QPlainTextEdit widget and it is not cool. One ends up with two different things trying to decide via different rules if a selection is in progress.

Under EDT, LSE, and a couple of mainframe editors, you hit one key to begin a selection. Here is a screen shot from Jed.

Jed and a lot of older editors used <Ctrl>B to begin mark. With EDT and LSE it is the period on the numeric keypad.

Setting the mark isn't my current question though. What I need to know is how does one determine a mark has been set without any characters having been selected?

In the older editors you set a mark then moved your cursor in whatever direction you wanted to select text. EDT, being from some time in the 1970s (whenever the VT-52 got a numeric keypad) needs to operate in this manner.

I also tried anchor() and it seems to always have the caret position.

There has got to be some way to know a mark has been set before any character is selected. Isn't there?

[Mitchell]

Hi,

On Mon, 16 Aug 2021 16:38:20 -0700 (PDT)
"'seasoned_geek' via scintilla-interest" <scintilla...@googlegroups.com> wrote:

> All,
>
> This should be fall off a log simple, but the doc isn't clear and my first
> interpretation appears to be incorrect.
>
> Because there is navigation going on that isn't controlled by the
> ScintillaEdit widget under C++, I have need of determining if a selection
> is currently happening or not so I can call normal move functions or their
> Extend() versions. I was using selectionStart() under the false assumption
> it would only have a value > -1 when a selection was in progress. Turns out
> selectionStart() always returns the current carret position.
>
> Please tell me the widget doesn't rely on an anchor and carret being
> different like far too many PC based designs. I had to dance around that
> with the QPlainTextEdit widget and it is not cool. One ends up with two
> different things trying to decide via different rules if a selection is in
> progress.
>
> Under EDT, LSE, and a couple of mainframe editors, you hit one key to begin
> a selection. Here is a screen shot from Jed.
>
> [image: jed-begin-region.png]
> Jed and a lot of older editors used <Ctrl>B to begin mark. With EDT and LSE
> it is the period on the numeric keypad.
>
> Setting the mark isn't my current question though. What I need to know is
> how does one determine a mark has been set without any characters having
> been selected?

SCI_GETMOVEEXTENDSSELECTION should provide the information you need.

Cheers,
Mitchell
Cheers,
Mitchell

[seasoned_geek]

Mitchell,

Thank you for your response. That does not appear to have the information.

    case Qt::Key_Period:    // select
    case Qt::Key_Delete:
        qDebug() << "moveExtendsSelection() before: " << moveExtendsSelection() << "\n";
        qDebug() << "selections before: " << selections() << "\n";
        qDebug() << "selectionMode before: " << selectionMode() << "\n";
        setSelectionStart(currentPos());
        qDebug() << "selectionMode before: " << selectionMode() << "\n";
        qDebug() << "moveExtendsSelection() after: " << moveExtendsSelection() << "\n";
        qDebug() << "selections after: " << selections() << "\n";

When I press the keypad period key I get the following:

moveExtendsSelection() before:  false

selections before:  1

selectionMode before:  0

selectionMode before:  0

moveExtendsSelection() after:  false

selections after:  1

If I use <Shift><Right Arrow> to select a piece of text then hit the keypad period key, I see the following:

moveExtendsSelection() before:  false

selections before:  1

selectionMode before:  0

selectionMode before:  0

moveExtendsSelection() after:  false

selections after:  1

I honestly expected selections to increment to 2. No such luck.

[Mitchell]

Hi,

The documentation for SCI_GETMOVEEXTENDSSELECTION states "This returns 1 if regular caret moves will extend or reduce the selection, 0 if not. SCI_SETSELECTIONMODE toggles this setting between on and off."

I don't see an indication of you calling SCI_SETSELECTIONMODE() anywhere in your code. This feature only works for marking a selection anchor at the current position and then using movement keys like the arrow keys to extend the selection, not shift+arrow.

It's possible I'm misunderstanding your use case.

Cheers,
Mitchell

[seasoned_geek]

No, you are not misunderstanding, at least not completely. I literally just got that part to do that

selectionMode before:  0

moveExtendsSelection() before:  false

selections before:  1

selectionStart before:  697

selectionEnd before:  697

selectionMode after:  0

moveExtendsSelection() after:  true

selections after:  1

selectionStart after:  697

selectionEnd after:  697

moveExtendsSelection():  true

    case Qt::Key_Period:    // select
    case Qt::Key_Delete:

        qDebug() << "selectionMode before: " << selectionMode() << "\n";

        qDebug() << "moveExtendsSelection() before: " << moveExtendsSelection() << "\n";
        qDebug() << "selections before: " << selections() << "\n";

        qDebug() << "selectionStart before: " << selectionStart() << "\n";
        qDebug() << "selectionEnd before: " << selectionEnd() << "\n";

        setSelectionMode(SC_SEL_STREAM);

        qDebug() << "selectionMode after: " << selectionMode() << "\n";

        qDebug() << "moveExtendsSelection() after: " << moveExtendsSelection() << "\n";
        qDebug() << "selections after: " << selections() << "\n";

        qDebug() << "selectionStart after: " << selectionStart() << "\n";
        qDebug() << "selectionEnd after: " << selectionEnd() << "\n";

The use case is:

No matter how a selection is started, <Shift><Arrow Key>, mouse, or numeric keypad, I should be able to determine a selection is in progress and have keypad navigation extend it.

Calling setSelectionMode() works only for pure keypad navigation.

Ultimately what I'm searching for are one or more signals coming from the C++ base class. Say . . .

#define SCI_SELECTION_STARTED some-value

#define SCI_SELECTION_CLEARED some-other-value

#define SCI_SELECTION_COPIED some-different-value

#define SCI_SELECTION_DELETED some-etc-value

    CS_SIGNAL_1( Public, void selectionChanged( int statusChange, int anchor, int caret ) )
    CS_SIGNAL_2( selectionChanged, statusChange, max, page )

I transmogrified the existing Qt code so in ScintillaEditBase.h you would be looking for this:

signals:
    void horizontalScrolled(int value);
    void verticalScrolled(int value);
    void horizontalRangeChanged(int max, int page);

Perhaps the underlying Scintilla code is already emitting something via some message and I simply need to add support for signalling it out? I haven't dug that deep yet. I was hoping there was something obvious in the documentation I was missing.

Alternatively, what would be cool is to have all of the existing <Shift><Arrow Key> and mouse selection logic simply turn on moveExtendsSelection() but that would probably break a lot of behavior in the field. People might have gotten used to being able to clear a selection by hitting a navigation key without holding down a shift key.

Honestly, if Scintilla.h just had

#define SCN_SELECTION_STARTED 2100   // whatever

#define SCN_SELECTION_CLEARED 2101

#define SCN_SELECTION_COPIED 2102

#define SCN_SELECTION_DELETED 2103   // or cut if you prefer

and it came to the base class in an SCNotification() so it could be signaled out, I don't need any other information. I don't see any #define in Scintilla.h that leads me to believe the selection begin/end are communicated to the consumer.

What is happening here is a collision of historic UI practices and a tiny bit of an oddity in the widget itself. Older editor interfaces (pre-PC and mouse) were all mark then move. Selection started when you dropped the mark and any navigation method in any direction adjusted the selection. Scintilla seems to have that with setSelectionMode().

This doesn't play well with the mouse and <Shift> selection methods. Actually these two methods don't really play well with each other.

Begin a selection with a mouse then switch to <Shift> and arrow key. Selection will adjust properly.

Begin a selection with <Shift> arrow and try to extend with mouse. Selection clears instantly.

Begin a selection with setSelectionMode() and navigate a bit via the keypad. Navigation by arrow keys and Page Up/Down adjust the size of the selection. Mouse click clears selection instantly.

Begin selection with <Shift> arrow key and select some text. Hit the keypad period key to call setSelectionMode(). Keypad navigation will now adjust select range. Mouse click clears selection instantly.

I don't know. Let me mull it over a while. With previous versions of this editor using just the QPlainTextEdit of CopperSpice I was able to keep this in sync. (Not well though as two different entities were trying to keep track of selection.)

Maybe I just need to check __both__ moveExtendsSelection() and for a difference between selectionStart() and selectionEnd()? That would be relying on the editor widget keeping the end set to the start when a selection wasn't active. I seem to remember reading that in the doc.

Sorry for the long post to those who don't like to read. This is how my thought process works. I write it all down to help it turn the gears.

[Mitchell]

Hi,

> *The use case is:*

>
> No matter how a selection is started, <Shift><Arrow Key>, mouse, or numeric
> keypad, I should be able to determine a selection is in progress and have
> keypad navigation extend it.

That's hard. You'd probably want to tap into SCN_UPDATEUI and check for SC_UPDATE_SELECTION. I don't know if there is a fool-proof way of doing this though.

> Calling setSelectionMode() works only for pure keypad navigation.

Correct. That is what I use it for.

> Ultimately what I'm searching for are one or more signals coming from the
> C++ base class. Say . . .

I think SCN_UPDATEUI is the only option for responding to selection updates.

Cheers,
Mitchell

[Neil Hodgson]

seasoned_geek:

> The use case is:
>
> No matter how a selection is started, <Shift><Arrow Key>, mouse, or numeric keypad, I should be able to determine a selection is in progress and have keypad navigation extend it.

Most selection in Scintilla is modeless.

Move the caret to position 1 with no characters selected; press shift right once; then shift right a second time. When has the selection been completed and how can you tell?

Neil

[seasoned_geek]

If I'm talking out my ass here because I haven't dug deep enough, please feel free to point it out.

#define SCN_SELECTION_STARTED 2100   // whatever

#define SCN_SELECTION_CLEARED 2101

#define SCN_SELECTION_COPIED 2102

#define SCN_SELECTION_DELETED 2103   // or cut if you prefer

I duth maketh the ASS-U-ME tion that when a selection is cleared, copied, or deleted/cut, the selection highlighting goes away.

It is my belief that once a selection is in progress, it stays that way until it is cleared, copied, or deleted. The selection "ends" with one of those three activities. One has either started a selection or they haven't. Once one starts a selection they are in selection mode until one of those three things happen.

Having said that, I imagine there are a lot of x86 only people who have gotten used to being able to press <Shift> Arrow key, move around for a bit that way, then let up on <Shift> and have the selection clear with the next Arrow Key press. That means the existing behavior cannot change without honking some/many/at-least-one person off. The signalling, however, would not change existing behavior and would allow editors that want selection functionality to "play nice" with each other to "Make it so Number One."

I'm just suggesting. I think I've jury rigged what I need comparing selectionStart() and selectionEnd().  Won't know for certain until I do more testing.

After that I need to look into a flavor of delLineRight()/Left() that actually removes the bounding new line character(s). Those two existing functions work perfectly for the [GOLD][2] directionally sensitive functionality.

That, however, is a task for some time tomorrow. Time for supper, some Chardonnay, and some streaming.

[Neil Hodgson]

seasoned_geek:

> I duth maketh the ASS-U-ME tion that when a selection is cleared, copied, or deleted/cut, the selection highlighting goes away.

When ‘copy’ is performed, the selected range does not change and can be modified (by shift right, for example). There are other commands (make upper-case, for example) that leave the same range selected and that selection range can be extended after the command. Are you going to send another SCN_SELECTION_STARTED when the selection is extended after the make upper-case?

Neil

[seasoned_geek]

#define SCN_SELECTION_STARTED 2100   // whatever

#define SCN_SELECTION_CLEARED 2101

#define SCN_SELECTION_COPIED 2102

#define SCN_SELECTION_DELETED 2103   // or cut if you prefer

#define SCN_SELECTION_UPCASED 2104 ...

Notify message: NotificationNumber  bool selectionActive

Granted the bool value on started, cleared, deleted, will probably always be false. All of the other situations where something was done and it remained active the bool would be true. The consumer of the widget could then decide if they wanted to turn the selection off or not.

Just a suggestion.

Right now, the consumer of the widget has to know how the widget operates internally to do much with selection behavior. There are currently two different selections methods within the widget and they don't play well together.

There is the PC era Start-End/Anchor-Caret where something has to actually be selected for a selection to be started (most likely to make mouse support easier).

There is the terminal era method of dropping a mark (turning selection on) then letting all navigation extend the selection.

Neither method really knows about the other. For a consumer of the widget to integrate them the consumer has to know how selections work internally. There is no one&done query the consumer of the widget can make isSelectionActive(). One has to both know the anchor points and check them and one has to also know what to check for the terminal support method.

If the widget could signal out every time it did something with a select range then the consumer could keep track.

If there was a one&done isSelectionActive() type call a consumer could check they could also remain blissfully ignorant of how selections happened internally.

I'm just thinking out loud here guys. Maybe for many use cases there is a reason for the consumer of the base class to be more tightly coupled? I'm not that far into my recreation of RedDiamond to know for certain. Currently working on Example3 for the CopperSpice fork/port/whatever of Scintilla. Examples one and two are already part of the code base.

[John Ehresman]

I think that you have a different model for how a text editor should work than the one that scintilla implements. There’s no concept of the editor being in the process of selecting in most cases; rather selections are changed by different command. For example, shift-left will expand whatever the current selection is by one character to the left (in most cases) without the editor entering a selecting state.

It may be better if you start with what you want to do and then ask how you can accomplish it with scintilla.

John

> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/92dcc45e-e93c-494e-8cda-afa118d3471an%40googlegroups.com.

[seasoned_geek]

In a thimble:

Scintilla has three different selection modes/methods:

1. Use the mouse - selection ends and clears by a different mouse click or any form of non-shifted navigation.
   
2. Use the shift and navigation keys like the arrow and page keys - selection ends and via mouse click or non-shifted navigation.
   
3. Drop a mark via setSelectionMode() and use non-shifted navigation keys. One has to programmatically end this selection.
   

I want to be able to make the three modes/methods play nice with each other. Currently they do not.

Clarification:

I want to be able to make the three modes/methods play nice with each other without having to delve into the inner workings of the widget.

[John Ehresman]

You may need to explain what you mean by making the ways of selecting play nicely with each other. I think they do work reasonably well together so I don’t know what to suggest. What are you trying to accomplish — e.g. implement an emacs or vi keybinding, change colors when a user selects with a mouse, etc?

Thanks,

John

> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/fc14a320-1405-4ae9-90d7-fa54582040e3n%40googlegroups.com.

[seasoned_geek]

I've almost got it working in Example3. I've had to track multiple things to do it. There wasn't a single point of tracking if the widget thought a selection was in progress.

"Play nice" == "Start selection with any of the current methods and continue with any other"

Currently this does not happen.

If you begin selection with a mouse and hit an arrow/navigation key, selection clears.

If you start selection with a <Shift> arrow key and slip off the shift for one of the arrow/navigation key hits, the selection clears.

If you select a big block, then click somewhere with a mouse, the selection clears.

Like I said, I've almost got it for Example3. Having to sync the selection methods in the derived widget though.

[John Ehresman]

The widget does _not_ track if it thinks a selection is in progress (most of the time) and because it does not track this, it cannot emit signals when it changes. This is what I was trying to get at when I suggested that you have a different model for how a text editor should work than the one that scintilla implements.

The cases you list where selecting stops are intentional. For example if you select a block with the mouse and then press an arrow key, the selection clears because most text editors works that way. If you want some different behavior, you need to watch for keystrokes / mouse events / etc and implement the behavior you want. The different behavior could maybe be added to scintilla but it would be a change to scintilla, not something that’s already there and just needs to be exposed.

John

> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/48879fd0-95de-448d-91e0-a17137a870d4n%40googlegroups.com.

[seasoned_geek]

The widget does track it. The fact it is in selection mode simply isn't made available to derived classes without them having knowledge of the internals or without digging into the UI updates that also track the selection. SCI_MOVESELECTEDLINESUP/DOWN should make tracking self-evident. The widget has to track the selection in order to move it.

As I said, I'm not asking you or anyone to change the basic behavior of Scintilla itself. The editor I'm making out of Scintilla will work the way most of the editors I've used work. To do that, I need a clean, reliable, non-intrusive method of determining if the widget is in selection mode. Originally I was asking for some "notify" messages to push the tracking of selection mode up to CsScintillaEditBase. Ultimately I got about 85% of what I wanted with the following

In constructor

...

connect(this, &EdtBaseWidget::buttonReleased, this, &EdtBaseWidget::syncSelectionMode);

...

void EdtBaseWidget::keyPressEvent(QKeyEvent *event) {
    int key         = event->key();
    int modifiers   = event->modifiers();

    bool handled    = false;
    bool isKeypad   = (modifiers & Qt::KeypadModifier);
    bool hadGold    = (m_previousKey == m_goldKey);

    m_previousKey   = key;

    if (hadGold) {
        handled = handleGoldKeySequence(key, modifiers, isKeypad);
    }

    if (!handled && isKeypad) {
        handled = handleKeypadSequence(key, modifiers, isKeypad);
    }

    if (!handled && (m_f12Backspace && (key == Qt::Key_F12))) {
        if (selectionActive()) {
            homeExtend();
        } else {
            home();
        }
    }

    if (!handled) {

        CsScintillaEdit::keyPressEvent(event);
    }
}

...

bool EdtBaseWidget::handleKeypadSequence(int key, int modifiers, bool isKeypad) {
    bool retVal = true;
    if (!isKeypad) {
        return false;
    }

    // We don't use all of these modifiers, but this will
    // save you the trouble of finding them.
    //
//    bool isShift    = (modifiers & Qt::ShiftModifier);
//    bool isCtrl     = (modifiers & Qt::ControlModifier);
    bool isAlt      = (modifiers & Qt::AltModifier);
//    bool isMeta     = (modifiers & Qt::MetaModifier);


    switch (key) {
    case Qt::Key_0:         //Move Line
    case Qt::Key_Insert:
        if (selectionActive()) {
            moveLineExtend();
        } else {
            moveLine();
        }
        break;

    case Qt::Key_Period:    // select
    case Qt::Key_Delete:

        setSelectionMode(SC_SEL_STREAM);
        break;
    case Qt::Key_Enter:     // Subs
        notDone("SUBS");
        retVal = false;
        break;
    case Qt::Key_1:         // move word
    case Qt::Key_End:
        if (selectionActive()) {
            moveWordExtend();
        } else {
            moveWord();
        }
        break;

...

bool EdtBaseWidget::selectionActive() {
    bool retVal = false;

    bool moveExtends = moveExtendsSelection();

    if (moveExtends || (selectionStart() != selectionEnd())) {
        retVal = true;
    }

    // sync keyboard selection method with whatever started selection
    //
    if (retVal  &&  !moveExtends) {
        setSelectionMode(SC_SEL_STREAM);
    }

    return retVal;
}

void EdtBaseWidget::resetSelection() {
    setSelectionMode(SCI_CANCEL);
    setSelectionStart(currentPos());
    setSelectionEnd(currentPos());
}

void EdtBaseWidget::syncSelectionMode(QMouseEvent *event) {
    Q_UNUSED(event)

    selectionActive();
}

Example3 is by no means done, but I have checked in this version. You can find it in the CsScintilla tree under copperspice_examples.

https://sourceforge.net/u/roland_hughes/csscintilla/ci/CsScintilla/tree/

If you have CopperSpice installed under /usr/local tree you can pull down the source tree and cd to the copperspice directory

./build_csscintilla.sh fresh

cd ../../csscintilla_build

sudo ninja install

That will get you a tentative port of Scintilla to CopperSpice installed under /usr/local

After that just navigate to the copperspice_examples directory tree

./build_copperspice_examples.sh

Don't try any of the RPM and Debian package building stuff. I don't have it updated and it will probably try to build RedDiamond.

In Example3 a user can start a selection with the mouse then use the standard navigation keys or the numeric keypad keys to change the size and shape. It still "feels" a big hokey but it might grow on me. I suspect I will eventually push selectionActive() down to CsSctinillaEditBase and give it a bool parameter to allow a user to force synchronization. Also find a way to avoid calling a bool returning method without ignoring the bool and a sync method that won't force a second call to moveExtendsSelection().

The only minor regret is clicking of the mouse after a selection is in progress does still clear it. I think I can live with that for now.

Should probably push resetSelection() down into CsScintillaEditBase now that I look at it.

Thanks to everyone who chimed in on this and offered helpful suggestions.

When I get done with the ExampleN programs (originally going to be 5, but now 7 probably) I will finish the Debian and RPM packaging scripts then that should mostly be it.

[seasoned_geek]

...errr

It still "feels" a big hokey

should read

t still "feels" a bit hokey

sorry for typo

[John Ehresman]

I’m pretty sure Scintilla does not track whether it’s selecting. SCI_MOVESELECTEDLINESUP/DOWN just take an existing selection and modify the document based on it (I’m probably over-simplifying; they should work when there are 2+ selections).

That said, you’re probably on the right track in overriding the key and (probably) mouse event handling to implement the behavior that you want.

John

> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/d91c320c-6673-4ca0-b13a-5820b1df0875n%40googlegroups.com.

[Lex Trotman]

IIUC the model Scintilla uses is that it _has_ a selection, not that
it _is_ selecting. The various
shift-arrow/shift-click/buttondown-mousemove actions _extend/reduce_
the selection, one character at a time (or many characters if you move
the mouse vertically). But they are all edge triggered, "this action"
-> "change the current selection". There is no mode "selecting".

So a sequence of select extend actions like shift-arrow or
buttondown-mousemove will each perform the extend and thats it. If
the next action is also a select extend, then that will be actioned,
or if the next action is one that removes the selection then that will
be actioned. It is not modal, each user action does the same thing
each time its actioned. If you read
https://www.scintilla.org/ScintillaDoc.html#KeyboardCommands you see
that there are a heap of move-extend actions that can be bound to
keys, there is no enter-select-mode.

Agree with John that the right method of implementing something else
is to capture the user actions before Scintilla and implement your own
semantics.

Cheers
Lex

> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/060451E8-AAAA-45EC-ACCD-C72821D4D325%40wingware.com.

[Neil Hodgson]

‘seasoned_geek’:

> bool EdtBaseWidget::selectionActive() {
> …

> // sync keyboard selection method with whatever started selection
> //
> if (retVal && !moveExtends) {
> setSelectionMode(SC_SEL_STREAM);
> }

This will convert a rectangular selection (and other non-stream selection types) to a stream selection which may be unexpected.

As the others have said, Scintilla does not support the concept of ‘is selecting’. The nearest similar feature is detecting whether the selection is empty (SCI_GETSELECTIONEMPTY).

Neil