Open ebraminio opened 7 years ago
CodeMirror computes the order of bidi text independently from the browser, for the purpose of cursor motion and drawing the selection. Styling pieces of content with non-default unicode-bidi
values will unfortunately put this computation out of sync, and produce the issue you describe.
It is not clear to me what we could do about that (getting the computed style for each token and somehow taking that into account when computing the bidi ranges would be too expensive and complicated).
Do you see any other way for CM be able to implement someway for isolating bidi of cm-string and/or any other chosen elements? If so the improvement can help many different project. For example on Chrome DevTools, this is correct while viewing:
(which here is its related patch)
but incorrect on editing, which uses CM:
(original testcase is <h1 title="متن">متن</h1>
which is also broken on plain text but I hope we could do better on CM)
It'd be possible to implement something like this, but I don't currently have the time to work on it, and as I mentioned, it'd be complicated (the bidi code is already quite scary).
No problem. Just wanted to know about the possibility. Thanks.
I think this is related to #4006.
I think also that can be resolved if unicode-bidi is taken into consideration.
Steps to repro:
print('\n'.join(['متن متن', '123']))
.cm-string { unicode-bidi: isolate; unicode-bidi: -webkit-isolate; }
to your browser CSSsActual: You can select the first word. While step 2, fixes the visual issue I've describe here, it breaks the editing experiencing I've described here
Expected: That CM won't care about unicode-bidi state, or even better, the CSS mentioned above be added to CM CSSs to help issues like this, in addition to fixing the issue with isolate bidi.