Current Ace editor widget assumes a monospace font, which fails horribly on bidi, Indic texts, CJK text, combining characters, surrogate pairs etc. Since comments and strings are often in non-English languages, this is crappy to work on code in those languages.

CodeMirror seems to handle these much better.

Strong oppose! Now you have deployed Ace Could editor with its API, its functionality and its keyboard shortcuts can can't turn 180°.

Hmm, what particular API? All of ACE?

See for example https://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/CodeEditor#Code:_CodeEditor_deaktivieren and http://ace.c9.io/#nav=api&api=editor -- one usually does deploy something if one is sure it is relatively stable but I cannot understand why CodeEditor was deployed despite this bug.

Software that's broken gets replaced with working software all the time. reopening.

(In reply to comment #2)

Strong oppose! Now you have deployed Ace Could editor with its API, its
functionality and its keyboard shortcuts can can't turn 180°.

Part of this bug would be figuring out what interfaces are exposed currently, what it would cost to port those interfaces over (if any), and figuring out the other potential consequences of making this switch.

Plus, if Ace is falling short, it would be good to evaluate whether we can hack on it to make it better (and figure out whether fixing up Ace is a better approach to take rather than switching completely).

I don't think we have enough info yet to say whether this is a wontfix or not. I agree that we ought to strive for some level of stability in tools we deploy. Breaking changes should be avoided if possible. Time is finite, developer time even more so.

(In reply to comment #5)

Software that's broken gets replaced with working software all the time.

And regarding deployment of unstable software, certain WMF Engineers and developers seem have a leading role recently.

(In reply to comment #6)

Part of this bug would be figuring out what interfaces are exposed currently,

The whole Ace editor interface:

mw.util.$content.find( "#wpTextbox1" ).data( "wikiEditor-context" ).codeEditor
( http://ace.c9.io/#nav=api&api=editor )

OK let's try bug 54136 before trying a total editor switch...

The problems I've run into with ace suggest that what it needs is a complete rework of its interface - issues include things such as poor contrast, hardcoded styling (preventing effective user-side fixing of stuff like the contrast, fonts, etc), dependency on wikieditor (including forced reenabling for anyone who's turned it off), a lack of support for system-side advanced clipboards or even moving around text by dragging it...

CodeMirror only has some of these issues.

moving around text by dragging it

This is possible with ACE. You can even config the delay after which the drag&drop starts. CodeMirror is also not able to drag to outside the editor.

poor contrast

Please look at the demo: http://ace.c9.io/#nav=about&api=editor
I also don't know why the background is blue in MediaWiki by default.

(In reply to comment #10)

hardcoded styling

http://ace.c9.io/#nav=api&api=editor .setStyle() allows you adding a class, .setFontSize() the font size and with that it isn't possible to overcome the issue?

dependency on wikieditor

I doubt this dependency is required. I also do not like it a lot.

BTW, did you check out the Default-Keyboard-Shortcuts?
https://github.com/ajaxorg/ace/wiki/Default-Keyboard-Shortcuts

(In reply to comment #11)

moving around text by dragging it

This is possible with ACE. You can even config the delay after which the
drag&drop starts. CodeMirror is also not able to drag to outside the editor.

Doesn't work consistently cross-browser, then.

poor contrast

Please look at the demo: http://ace.c9.io/#nav=about&api=editor
I also don't know why the background is blue in MediaWiki by default.

That page just didn't load at all, but is somewhat reassuring. Requiring users to know js and other weird stuff to configure it, however, is decidedly poor practice, especially when it's drastically changing defaults and overriding browser and system settings. Perhaps these are issues specifically with the extension, however.

nzmoihue wrote:

I guess with switching to CodeMirror these will be fixed Bug 55422, Bug 45876 and it doesn't need indirect find in page I guess.

nzmoihue wrote:

RTL word selecting compare

And CodeMirror is acting better then Ace on RTL text selecting.

Attached:

I think you can consider using https://github.com/Microsoft/monaco-editor also, it supports right to left languages much better than ace https://github.com/ajaxorg/ace/issues/1429 (which made CodeEditor pretty useless on our wiki).

I hosted Monaco on toolserver and brought a working example with it here https://fa.wikipedia.org/?withJS=MediaWiki:Monaco.js now I like to see if I am able to replace ace with monaco with some gadget code.

In T50826#2708694, @Ebraminio wrote:

I hosted Monaco on toolserver and brought a working example with it here https://fa.wikipedia.org/?withJS=MediaWiki:Monaco.js now I like to see if I am able to replace ace with monaco with some gadget code.

I must note it's super heavy. It would be nice to let the user choose which code editor they want in preferences. I don't think implementing it would be hard.

Proposing this as a wish

This proposal is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

Anyone interested in mentoring this task for Google Summer of Code 2017 or Outreachy Round 14?

After all these years RTL editing issue of Ace is fixed https://github.com/ajaxorg/ace/pull/3137 when that is released as a stable version, the fix will be very beneficial for RTL wikis to have but there are still some issues with languages that don't have monospaced fonts for editing (e.g. Indic languages) which is also considered for fix but I guess that would also take some time.

(cross posting with T141395)