The motivation behind this is allowing cursors to be synced from within prosemirror nodes with editable custom views which propagate changes to the parent prosemirror editor. See the classical example https://prosemirror.net/examples/codemirror.
When such a node-view gains focus, prosemirror root view is blurred. Therefore, in the current implementation, the local field for sharing cursor position is deleted and not synced any more.
If we'd make, in addition, getSelection a function of the editor view instead of its state, we could allow users to reflect on the view's focus for opting out of syncing cursors by providing their own function.
I couldn't find anything specific in git history which motivates the focus assumption as opposed to checking for a selection object alone. Any pointers on how to work around this limitation in a different way is very welcome and of course many thanks to @dmonad for their work on this library!
The motivation behind this is allowing cursors to be synced from within prosemirror nodes with editable custom views which propagate changes to the parent prosemirror editor. See the classical example https://prosemirror.net/examples/codemirror.
When such a node-view gains focus, prosemirror root view is blurred. Therefore, in the current implementation, the local field for sharing cursor position is deleted and not synced any more.
If we'd make, in addition,
getSelectiona function of the editorviewinstead of itsstate, we could allow users to reflect on the view's focus for opting out of syncing cursors by providing their own function.I couldn't find anything specific in git history which motivates the focus assumption as opposed to checking for a selection object alone. Any pointers on how to work around this limitation in a different way is very welcome and of course many thanks to @dmonad for their work on this library!