Rationale for inclusiveRight→inclusive change

1

We’re upgrading from 0.10 to 0.19, and had code that relied on inclusiveRight only applying to the right.

Background:

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.

Question:

I see in Add inclusiveLeft and inclusiveRight properties to MarkType by kiejo · Pull Request #287 · ProseMirror/prosemirror · GitHub 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.

2

This kind of sounds like you are believing that inclusiveRight was not the default. You don’t have to ‘enable’ it – if you want marks to apply to text typed on its edges, just don’t disable inclusivity.

That still works, doesn’t it?

Marks are never left-inclusive, unless there is no inline content before them. For regular inclusive marks, the behavior did not change at all.

As for the background, did you see this discussion?

1 Like
3

Great explanation thanks! I had missed the discussion, so that was a useful read too.

I think the missing pieces in my understanding were:

  • inclusive is inclusive-right only — unless there’s no inline content before — otherwise it’s both inclusive-left and inclusive-right. This means that in my case of user-mentions, there would be different behaviour if a paragraph started with an @brad text compared to if it was a few words in.
  • pm.activeMarks() has the same logic as ResolvedPos.marks().

NB: Perhaps a nice benefit of removing Left / Right from the API is it’s more BIDI friendly — where terms like leading/trailing might be more appropriate.

4

That’s a good point. I think after this change only the inclusiveLeft/inclusiveRight for inline decorations remain. Would you agree that inclusiveStart and inclusiveEnd would be appropriate terms?

(Edit: not sure why discourse keeps eating my spacing in the sentence above. Editors are hard, I guess.)

1 Like
5

That sounds good to me.

6

This patch does the renaming of inclusiveLeft and inclusiveRight.

1 Like