Interaction of CodeMirror with other tools needs to be improved.

In rECMI /resources/ext.CodeMirror.js lines 120/121 read today:

// FIXME: Would be good to replace the wikEd check with something more generic.
if ( mw.user.options.get( 'gadget-wikEd' ) > 0 ) {

Well, that’s right. This epic should provide some building blocks for better collaboration of CodeMirror, wikEd and CodeEditor.

Strategy

• The current approach says: If there is any hint that any of the concurring tools might have been loaded then terminate immediately.
• This is no valid strategy, at least not for all three.
• It will end up in a race condition which toolbar and buttons are presented to the user.
• In 2018 CodeMirror is always present for every user.
• It does no harm if others are sleeping in background.
• It is not possible to activate a highlighter while another highlighter is already occupying the textarea. This is the condition which needs to be excluded.
• Finally a situation might arrive that several tools are presenting their buttons. A user might switch on CodeMirror, switch off CodeMirror, switch on wikEd, without any problem. This is the target here.

Initialization

For each account the last button click of CodeMirror in any browser tab is recorded on wiki server. This is used for initialization when entering a new page. That is fine, but it needs to be corrected locally acording to the current environment. The following algorithm needs to be evaluated:

• IF mw.user.options.get( 'usecodemirror' ) > 0
• AND there is any highlighting tool occupying textarea
• THEN reset CodeMirror activation state locally to inactive.

But carry on, do not leave. Button will be shown, but with black pencil. CodeMirror highlighting will not start.

• Examination for conflict should happen again when a user clicked the button.

Since other tools need time to load and initialize the inspection of the neighbourhood should happen as late as possible.

• This is at DOM.ready despite being possible immediately when CodeMirror has been loaded.
• DOM.ready is sufficient since neither a button can be applied nor a textarea could be equipped earlier.
• However, each participant should communicate its intention as soon as possible to inform the others. For CodeMirror that is fulfilled by server option which is available even before thinking of page loading.

wikEd issues

wikEd is a popular tool, world-wide used and established in 2006. It hilites the textarea similar to CodeMirror goals and provides further functionalities.

Gadget registration

The current attempt is not reliable.

if ( mw.user.options.get( 'gadget-wikEd' ) > 0 ) {

• The project might have used any other ID than wikEd for registration, e.g. WIKED or wiked or wikEdCacycle or whatever.
• No gadget needs to be defined by the project.
• Any user might have chosen an indvidual loading procedure.

wikEd detection

On module level the following local is to be defined:

var wikEdProven;

Further evaluation is done within a detection function in two steps:

if ( ! wikEdProven   &&
     ( typeof window.wikEd  ===  "function"   ||
       ( typeof window.wikEd  ===  "object"
         &&     window.wikEd ) )    &&
     typeof window.wikEd.disabled         ===  "boolean"    &&
     typeof window.wikEd.highlightSyntax  ===  "boolean"    &&
     typeof window.wikEd.turnedOn         ===  "boolean"    &&
     typeof window.wikEd.useWikEd         ===  "boolean" ) {
   wikEdProven = window.wikEd;
}

This gives a fingerprint of the application object.

• A user might have polluted the global namespace with a string variable or whatever, not using the gadget. Then next step would crash CodeMirror.
• The test is done once if ever succeeded. If somebody overwrites the global object later the gadget breaks as well.
• If not successful at first attempt it is repeated every time, since the gadget may have been arrived meanwhile.

The next test asks for activated highlighting:

if ( wikEdProven   &&
     ! wikEdProven.disabled  &&
     wikEdProven.useWikEd    &&
     wikEdProven.turnedOn    &&
     wikEdProven.highlightSyntax ) {
   // wikEd is currently highlighting.
   // Do not perform CodeMirror highlighting now.
}

Actually wikEdProven.highlightSyntax would be sufficient, but the other tests make it fool- and bullet-proof.

• It might have been entirely disabled but last highlighting mode is still heading for activation.

The detection function is called on two occasions:

• On initialization after DOM.ready to block CodeMirror highlighting.
• On CodeMirror button toggle on to prevent switching to active.

Sleeping wikEd

When wikEd is not highlighting there are several inactive levels:

• It might be installed but not turned on, just residing in background.
• Navigation bars and buttons are offered. Several buttons jump to positions within the page. They do no harm.
• On the major wikEd toolbar in the second row the leftmost button is toggling on and off textarea highlighting.
• That button should consider preoccupation by another tool.

wikEd and CodeMirror today

In the 2017-11-05 release of wikEd, lines at 4115 test:

if ( window.mw.user.options.get('codemirror-syntax-highlight') == 1 ) {
   wikEd.useCodeMirror = true;

This does not work any longer.

• The option ID changed.
• It is supposed that user voted for beta test and might activate CodeMirror.
• Today, every user always has CodeMirror installed on source editing.

Later in process around line 2635:

// do not turn on when code editor is active
if ( ( wikEd.useCodeEditor === true) || ( wikEd.useCodeMirror === true ) ) {
   wikEd.disabled = true;
   wikEd.SetLogo('incompatible', 'Code Editor');
   return;
}

The question is not whether CodeMirror could be started. It could.

The server state of CodeMirror (and CodeEditor) needs to be inspected.

If one of them promises to become active, then highlighting shall be blocked for now:

wikEd.highlightSyntax = false;

The installation procedure may proceed as usual.

• Only when a user clicks the highlightSyntax button textarea needs to be checked for occupation.
• If conflict, simply do nothing. Perhaps console log.

A situation might arrive that all three tools detect that another one is heading for highlighting and refrain theirselves.

• No problem at all.
• The textarea remains in virgin state.
• All buttons are offered.
• It is up to the user to decide on action.

CodeMirror button

When a user clicks the black pen button, perhaps by incident, the current situation is to be examined.

• If any other tool is currently highlighting then simply do nothing. Perhaps console log.

CodeEditor

rECMI /resources/lib/codemirror/mode/ lists patterns for CSS, JS and more.

• A situation could result from configuration where both CodeMirror and CodeEditor try to work on the same textarea for a programming language.
• Both may be present, also showing buttons, but only one of them is permitted to govern the textarea at the same time.
• Same procedure as for the comrades.

Nuisance

Another textSelection API was already registered

See e.g. T186743 and other cases can be reproduced.

Only immediately when really highlighting textSelection.register() may be called, and when leaving hilite mode textSelection.unregister() needs to be called.

• See rMW /resources/src/jquery/jquery.textSelection.js for details.
• This goes for all partners.

mw.hook()

On this review situation it would be helpful for process communication if two mw.hook() events will be fired:

• CodeMirror.enabled as late as possible after highlighting, with CodeMirror application object as parameter.
• CodeMirror.disabled as late as possible after leaving highlight mode.