Should marks have direction-based inclusion affinity?


Currently marks can be inclusive or not. If they are inclusive, you are on the edge of content with a mark and add more content, the new content has the mark as well. This is to be used for bold mark, for example. Non-inclusive for links.

But this is sometimes hard to work with. I would suggest a direction-based inclusion affinity as an additional option. This could especially make extending link content easier, but it might also be nice for bold and other inclusive marks.

What I mean is that if I am with cursor inside a link and I move to the right end of the link by moving the cursor right with my arrow keys and start typing something, I would prefer that it extends the link. On the other hand, if I would be outside of the link on the right and would move to the left with arrow keys until the link and start typing, I would prefer that it does not extend the link. Otherwise it is really hard to get any content added beyond the end of the existing link.

Then regular “inclusion” property would control what happens if you “parachute” to the edge in some other way which does not have direction. But if you move there with anything where you can have direction the behavior could be like one mentioned above, if enabled.

Another case where this would be more intuitive (at least to me) would be if you are making a selection from the middle of the link to exactly the end of the link and you want to replace it with content. You make a selection, press a letter, and it is replaced with non-link content.


You could write a plugin that implements this, but I am not going to add it as default behaviour—it’s another piece of hidden state, and will probably confuse users more often than help.


Hm. Any suggestion how this could be implemented?

And I agree this should not be default.


A plugin could observe cursor motion and set stored marks with appendTransaction when appropriate.


I mean, I would have to turn on or off if the mark is inclusive based on cursor motion? Because then I could reuse existing logic of adding marks automatically to new content on the edge of a mark.

Is there a way to flip this at runtime for a particular mark?