[SuperEditor] - moving caret with up and down arrows generates a SelectionChangeEvent of type collapsedSelection

[JostSchenck]

current super_editor, main branch

I'm writing a reaction which has correct the caret position if the user has moved the caret into a region of the document which is supposed to be currently hidden. For this, I search the changeList for a SelectionChangeEvent of type SelectionChangeType.pushCaret. This works for simple upstream/downstream movement of the caret by pressing left or right arrows. However, when the user presses up or down buttons, the current implementation in CommonEditorOperations.moveCaretUp and moveCaretDown will instead produce a SelectionChangeType.collapseSelection, even when the selection was already collapsed before. Maybe I misunderstood the change types, but to me this naming is confusing.

I would expect moveCaretUp and moveCaretDown to fire an event of collapseSelection when there actually was an expanded selection before, else fire an event of pushCaret. If pushCaret for some reason was meant for one-step only movements, I'd rather expect another type of moveCaret.

I can work around this by reacting to collapseSelection as well; I still think this is confusing.

[JostSchenck]

Actually I think, regardless of that I find the current wording misleading, for my use case it would indeed be very useful if I could tell by the event if the caret was "pushed" by just a character (in which case I would for example move it to the beginning of the next visible text node, if it was moved to the right at the end of the last visible text node), or moved up or down (which needs knowledge about the layout, in which case I would rather continue firing commands to move it further up or down until it reaches a visible component, to be placed at the rigth horizontal position). See this screenshot:

The caret is placed at the end of the "First grand child" line. As this line is collapsed (as seen by the arrow pointing right), the children below are hidden. If I press "right arrow", the caret will move into a hidden node, and my reaction would move it to the next visible node, and there offset 0, as marked blue. If I press "down arrow" it should move to the green position.

It's quite probable, that in my use cases right now I can just assume "collapseSelection" with a following base in a hidden node can always be treated as if it happened by up or down arrow. So I'll just continue like that for now, but still think that the SelectionChangeTypes might have to be revisited a little.

[matthew-carroll]

@JostSchenck for clarity, can you list all the movement types that you think we should include?

[JostSchenck]

@matthew-carroll Generally, I would like to have a way of knowing in reactions when a movement was triggered by left, right, up, down, and possibly know if a by-word- or by-paragraph-modifier was used. This would allow for use-cases like mine to reuse more of the super_editor standard setup by implementing all required behaviors in the reactions.

[matthew-carroll]

@angelosilvestre can you spend a few minutes filling out a comment here about what we have vs what we need to fully offer these details?

I think this issue involves requests, commands, and events.

For example, consider moving selection by word. We probably want the following pieces:

• MoveExtentForwardByWordRequest
• MoveExtentForwardByWordCommand
• SelectionChangeEvent
  • direction: forward
  • distance: word

For each such situation, please note whether we already have the given request, command, and selection event details.

After you audit those details, we can circle back, finalize what we want, and then this ticket will be ready for work.