when multiple replace decorations in succession, caret breaks

I found when multiple replace decorations in succession,the caret breaks。Maybe it’s because there’s no widgetbuffer between decorations?How to fix this problem?


Should I set inclusive to true

This is on Chrome I assume? Can you say a bit more about where the cursor is when this happens, and, indeed, what the inclusive option to the decorations is?

Yes, it’s on Chrome. When I try to press ArrowLeft to move cursor between markers,the caret position is not right. But I found it’s because I only include partial basicSetup options,when I add drawSelection , it works. Are there any basicSetup options must be included?

It is recommended to use at least the extensions in minimalSetup (drawSelection, history, default keymap, and highlightSpecialChars).

Hi marijn,how to disable some default keymap,except use a high precedence

hi @marijn !

I seem to be having the same issue. I already use all the extensions from the minimal setup, but as soon as I render a widget, the cursor jumps.
with drawSelection, it jumps to the very end of the editor, with the native caret, it jumps to somewhere near the start of the editor, although the native caret does work in chrome, but not in safari (didn’t test firefox).

cursor at the end of the input, but visually
native:
Screenshot 2024-11-22 at 12.58.44

drawSelection:
Screenshot 2024-11-22 at 12.59.28

I have one decoration mark with inclusive: true, wrapping key-value pairs and a widget, nested inside the decoration to delete the pair.
depending on the input, the cm-widgetBuffer is either rendered next to the decoration’s span or moved inside the span, being the last element in there. looks like whenever it is inside the span, the cursor position is off.

do you have any idea how I could fix that?
@superdc did you do anything on your end that helped?

I’m currently trying to reproduce the behaviour with the widget buffer in the playground too, will post as soon as I have something.

managed to reproduce it.
this is the playground for testing. basically just setting up the grammar and a decoration mark that is set to inline-block. that seems to completely throw off the caret position in safari for both the native caret and when using drawSelection().

alternately typing a and space should show the issue, see attached gif, first typing and then just hitting backspace.
safari-caret-position

@marijn can you work your magic there?

All I can do is tell you not to mess with the display property of content rendered by the editor. You can make opaque widgets inline blocks, but wrappers around actual content must be inline elements.

that’s already something I can work with. thx! there should be some way to solve that without adjusting the display prop :crossed_fingers: