-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getCaretAtPoint(...) taking surrogate pairs into consideration #304
Comments
You're definitely right. The behavior you're showing is appropriate(ish) for ligature glyphs, but not for surrogates. I think we can add a check here for whether the indices were skipped due to ligatures vs. surrogates. We may also need to make some other adjustments in selectionUtils to make sure we walk back to the start of a surrogate and never return an inter-character index. |
Great. Assuming no one else gets to it by then, I can put some time aside to work on a PR for it towards the end of the month |
Currently
getCaretAtPoint(...)
does not take surrogate pairs into consideration. So if an emoji is present, the caret index found might be in the middle of it as emojis can span a variable number of code units (Attaching a gif to show an example of what I mean)What are your thoughts on the function only returning the indices before or after the whole surrogate pair and not the middle ones in the case of emojis/other complex characters?
This is definitely an edge case that could be handled on the client side, but I do think in the long run it would beneficial to have this support out of the box. I personally can't think of any reason one would want the index in the middle of some surrogate pair
The text was updated successfully, but these errors were encountered: