We’re upgrading from 0.10 to 0.19, and had code that relied on
inclusiveRight only applying to the right.
When someone types
@, we would apply the
user_mention_query mark to the text, and use
inclusiveRight to have further typing contribute to the “query” (by also being marked). The
user_mention_query mark indicates that the text is being used as the “search term” for a user mention. We have a plugin that presents a user-picker with search results based on the query.
We implemented the behaviour where the query is “discarded” (i.e. returned to normal text) if the cursor is placed at the start of the query (i.e. before the
@). We would watch for selection changes, and use
pm.activeMarks() to check if the mark is still applied.
The problem we face in 0.19 is that inclusive now includes left, and so
ResolvedPos.marks() cannot be used as a replacement for
pm.activeMarks(). We can work around it by tracking cursor-position (i.e. discard the query based on selection position), but it did raise the question of what motivated this API change.
I see in https://github.com/ProseMirror/prosemirror/pull/287#issuecomment-206321835 you said:
That latter patch removes inclusiveLeft since, on second thought, I can’t really see a use for it, it makes the start-of-parent situation a weird exception, and it removes a relatively nice property of the way marks work – that, when there is text before the cursor, the active marks are only dependent on this text.
What changed for
inclusiveLeft to become compelling enough to not only add, but to merge into
inclusiveRight? Understanding the background could inform our decision making about schema design in the future.