You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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 typeSelectionChangeType.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 inCommonEditorOperations.moveCaretUp
andmoveCaretDown
will instead produce aSelectionChangeType.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
andmoveCaretDown
to fire an event ofcollapseSelection
when there actually was an expanded selection before, else fire an event ofpushCaret
. IfpushCaret
for some reason was meant for one-step only movements, I'd rather expect another type ofmoveCaret
.I can work around this by reacting to
collapseSelection
as well; I still think this is confusing.The text was updated successfully, but these errors were encountered: