Controlling inclusive left/right of MarkTypes

1

Is there a way to control the way MarkTypes behave when typing at their edges? I know that the MarkedRange class allows setting inclusiveLeft and inclusiveRight options, but I couldn’t find anything on doing the same for MarkTypes.

My use case would be to set inclusiveRight to false for link marks as the current behavior prevents you from writing normal text in a paragraph whose last item is a link (you can only expand the link when typing at the end). The workaround is to create a new paragraph with some text below the paragraph with the link and then join both paragraphs.

Would be great be able to define these options on a schema level.

1 Like
2

Not really – you just have the disable the link style, just like you’d do for bold or emphasis.

But yeah, this might be a useful, straightforward feature to add. It will break the ‘enable and then type’ method of inserting links, but I guess I would disable it in the default schema.

3

Agreed this would be awesome! My current work around has been to hack the marksAt node method to remove links when it detects you are at the end of a link.

4

I hadn’t thought of that, but in our case we don’t want a menubar or hotkey for links and our setting is similar to the editor on the ProseMirror landing page, which has the same problem.

I think this shouldn’t be too big of a problem for links as enabling them before typing currently opens a modal dialog, which is different from the behavior of bold/emphasis where the ‘enable and then type’ functionality works really great. But either way it would definitely be awesome to have this feature!

5

Opened #285

1 Like
6

I’d really like if inclusiveLeft were a thing. I was happy to see it was and followed the rabbit hole here to find it was removed, to great sadness.

code marks just don’t feel right when you can’t type into the start of them.

7

To add to this - we could use custom logic to reproduce it but the caret still appears outside of the code when the user starts typing instead of inside, so it feels janky at best. The caret discrepancy is noticeable because its size changes (it’s shorter inside code.)

8

Caret style would be entirely unaffected by such a feature. The way the browser decides to draw the caret on an inline boundary is outside of the library’s control.

1 Like
9

@marijn sorry I opened a new discussion, I didn’t get notified of your reply here. I hadn’t realized that this was browser-controlled. Thank you for taking the time to reply.