Make cursor control configurable #4921
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
There are currently a lot of right-to-left bugs with CodeMirror that are caused by it exercising control over the cursor rather than allowing the browser to handle cursor control. (See https://github.com/codemirror/CodeMirror/issues/4878 and https://phabricator.wikimedia.org/T170001.) Although browsers also have RTL bugs related to cursor control, everyone I have talked to about this issue (including a professional RTL engineer) agreed that it is better to let the browser handle cursor movement. Whatever quirks the browser may have, people who write in RTL (or mixed RTL and LTR) are intimately familiar with those quirks and expect them. Replacing those quirks and bugs with our own quirks and bugs is counter-productive. The goal of making the behavior consistent across different browsers is a very small gain compared to the huge loss of people not being able to enter content in the way that they expect and having to deal with new RTL bugs.
I would like to ask that the cursor control feature be configurable, so that individual installations can turn the feature off if they see fit.
Though I agree that this is a good idea (and the approach I'm taking in ProseMirror), that's not possible with CodeMirror's architecture, since the selection is entirely managed and drawn by the library, and thus the browser can't be much help here.
@marijnh: Could you elaborate on that any? Would it not be possible to make all the dynamic features of CodeMirror optional and implement a "highlight-only" mode that does nothing but simple syntax highlighting?No, that definitely wouldn't be possible -- you can't highlight a textarea, so you'd be dealing with the full complexity of contenteditable. Also, a system that does only highlighting would be CodeMirror, it'd be something completely different.
This is one of many issues which are difficult to solve with the fundamental approach currently taken by CodeMirror.
We are working on a rewrite (CodeMirror 6) that will overhaul input handling and should address this issue, and we are currently raising money for this work: See the announcement for more information about the rewrite and a demo.
Note that CodeMirror 6 is by no means stable or usable in production, yet. It is highly unlikely that we pick up this issue for CodeMirror 5, though.