Custom tooltips

I’m looking to create custom tooltips in my react application for Codemirror 6. I see there is a hoverTooltip helper, but I am unable to find a good way to integrate this with React (and have my animations work as I want them to, etc).

Ideally, I would like some sort of plugin that will simply set/dispatch the information necessary, so that my custom tooltip component can react to it. This would be show/hide, x/y and pos in document.

I see that there looks to be a HoverPlugin that likely could fill this purpose, but I am unable to use it as it’s not exported.

Could anyone please provide some guidance on how I can achieve this.

Thank you.

I’ve also noticed that posAtCoords behaves quite a bit differently (worse, for me) from the previous implementation in version 5. It seems to return indices when you are hovering next to certain characters (looks like the width of a character almost?) and when you’re outside the bounds of the editor, it always seems to return 0, and not null.

When you hover widgets, for example a widget representing an invisible character, it does not seem like posAtCoords returns the same pos for the entire size of the widget, only for that corresponding to a normal character width. So if the widget is larger than a characters width, it doesn’t seem to work as expected.

Feel free to file bugs with specific misbehavior (and reproduction instructions).

I will try to make some time to create a minimal reproduction sample for you.

I have created an example here: adoring-ace-iyoejq - CodeSandbox

If you hover the special-car placeholders you will see the position switches to the next character after about one characters width.

You will also notice that the first character is selected as being hovered when you hover just above the text in the editor, as your mouse is leaving the editor.

@marijn Was the example sufficient? Should I submit it somewhere else?

posAtCoords doesn’t return a character, it returns a position, a place between characters, close to the given coordinates. That being said, the heuristic for which side to return when over a widget could be improved. See this patch.

You’re right, a position.

I’d be happy to try out this patch, do you know when it will be available to download?

I tried the patch out and updated my example to use the new code: adoring-ace-iyoejq - CodeSandbox

It does not seem to completely fix the issue. The “wrong” index is still returned after you pass the midway point.

See my previous message. This is intended behavior. If you want to go from a mouse event to the position of the widget, posFromDOM(event.target) is probably what you want.

Thank you for your help!

I’m facing some odd issues with the inverse, coordsAtPos, but I will open a new issue when I have a small repro example of what goes wrong. It seems calling this while scrolling the editor can cause some trouble, but I’m not sure if thats the best way to reproduce it.

I figured I’d share another bug with you, hope it’s OK I use the same thread.

If you check the example here adoring-ace-iyoejq - CodeSandbox you will see that calculating the rects of the characters produces the wrong height for the newline character when preceded by a “special character”.

If you replace \x01 with anything else, or place a regular character after it, the height is correctly calculated.

To make it clearer what I’m referring to, it’s the fact that all characters at 16px in height except for the newline character, which is reported as 13px in height.

Note that coordsAtPos does not measure a character. It measures a cursor position. Since it relies on DOM bounding rectangles it indeed does not guarantee that all the rectangles will correspond in height to the height of a non-styled letter.

1 Like