Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
JostSchenck opened this issue Oct 6, 2024 · 1 comment
Labels
type_bug Something isn't working

Comments

@JostSchenck
Copy link
Contributor

JostSchenck commented Oct 6, 2024

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 JostSchenck added the type_bug Something isn't working label Oct 6, 2024
@JostSchenck
Copy link
Contributor Author

JostSchenck commented Oct 6, 2024

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:
image
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type_bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant