$wgCodeMirrorAccessibilityColors is for the new color scheme added by WMDE. I believe enwiki is asking about enabling the CodeMirror user preference to be on by default ala $wgDefaultUserOptions['usecodemirror'].

In T288161#7263898, @MusikAnimal wrote:

$wgCodeMirrorAccessibilityColors is for the new color scheme added by WMDE. I believe enwiki is asking about enabling the CodeMirror user preference to be on by default ala $wgDefaultUserOptions['usecodemirror'].

However per T280024#7261161 it seems it's probably safe to turn on $wgCodeMirrorAccessibilityColors for enwiki as well, but it will be a matter of time before all wikis get the new colours.

Two points to consider:

• Editors have said that they don't know how to turn this on, which means that editors won't know how to turn it off. Maybe finding way to point this out is worth considering before making this change?
  • The reason I think this is important is because many editors will want to turn this off as quickly as possible. This is going to be at least as disruptive to some editors as when watchlist highlighting (to show which pages you'd already read since the last change) was enabled, and despite that also being the result of a request from English Wikipedia editors through a well-advertised, CENT-listed RFC at the Village pump, the day it happened, there were many angry editors, including at least one saying that bold-face text gave him a migraine. Having colorful syntax highlighting in every editing window is IMO not likely to get fewer complaints than having bold-fact text on one part of one page.
• Has anyone looked into the performance-related accessibility issues? For example, can this be auto-disabled for people who are using older computers or using the desktop site on a mobile device, or is there a timeout so that it will gracefully give up after a couple of seconds?

@Whatamidoing-WMF, I believe the performance issues from the past are resolved. The WMDE TechWish team invested quite some time looking into this. It was so bad, any larger page could potentially jam the editor for minutes (!). The main bottleneck was finally found and fixed via https://gerrit.wikimedia.org/r/655689.

If you want to help users find the button, I suggest to look into T174145 again.

wgDefaultUserOptions doesn't allow specifying it for accounts created after a timestamp and IPs only. I don't see any hooks that would allow changing the default options per user, and hooks like LoadUserOptions look like that they would allow this to be done but that could come with UI bugs and other weirdness.

Majavah, I'm not sure if this is the information you're looking for, but:

Syntax highlighting is "sticky", meaning that if you click the toolbar item to turn it on, it stays on in all of your subsequent editing sessions, and if you click in the toolbar to turn if off, it will stay off in all of your subsequent editing sessions.

If you wanted to pre-set it on for some users and off for other users, and iff the "sticky" setting is stored in the normal preferences database, then that should be theoretically possible by directly editing the prefs database for each account. However, that would be a Scary Thing™ and is probably not warranted for this subject.

@Aklapper is there a reason you removed the MediaWiki-extensions-CodeMirror project tag?

@Sdkb: This seems to be a request for a config change on Wikimedia servers, not a request to change code in the extension's code base repository.

by default for new editors

Just to clarify this is a very tricky part of this request (as @Majavah was implying as well). The only way to realise this, is to create a database migration, take ALL registered users WITHOUT this preference, SET the existing default for them, and then switch the default for all editors.

We tend not to do this, because it creates a ton of unnecessary rows in the database, esp considering that most 'current editors' are actually non-active users..... While this has been done in the past a few times, I can't remember the last time (maybe something VE related?).

So there are two parts to this ticket really:

• switching for anonymous editors is easy and a config change.
• switching for new editors requires custom code (migration script) that has to be run, followed by a config change (probably approval by DBA too actually)

And then there is the potential confusion, pointed out by @Whatamidoing-WMF, which possibly could be solved by an editor tour or something, pointing out to first time users where the button is and what it does... (more custom code)

So now we should decide which of these steps to take and in which order and who has to do them.

Thanks for the update, TheDJ. I might have structured the proposal a little differently if I'd known that doing things differently for new vs. current editors would be so difficult, but the way I did it probably made it easiest to achieve consensus. If ignoring inactive editors would make things easier, that probably would be fine, as they're unlikely to complain since they're, well, inactive.

Regarding WhatamIdoing's concerns, I think that's unlikely to apply if it's only new editors: they don't have prior expectations of the Wikipedia interface, so they're not going to have any attachment to a status quo or experience any disruption. We do want people to know how to turn it off, but that's what T174145 is for. Regarding the idea of a "tour" or pop-up box, I would be opposed to that, for the reasons I gave at the discussion. Copying here:

I would strongly oppose the pop-up box approach. When we think about the new editor experience, we need to be extremely selective about what information we present, as we want to get them to the point of having made a constructive edit before they give up. We're already asking them to read a lot of important things (e.g. copyright notice, plea to add references) and to decide between VE and source. Adding another box they have to click through builds the pile and introduces potential confusion (some people may think turning on syntax highlighting is activating the VE). I'd much rather use that valuable pre-edit moment to communicate core concepts like referencing than to explain this particular feature. We shouldn't force people to set up a whole comprehensive profile just to fix a typo.

In T288161#7292696, @Sdkb wrote:

Regarding WhatamIdoing's concerns, I think that's unlikely to apply if it's only new editors: they don't have prior expectations of the Wikipedia interface, so they're not going to have any attachment to a status quo or experience any disruption.

Many new editors were previously IP editors, and therefore do have some expectations about the interface. Some IP editors (for whom this ticket proposes enabling by default) have made thousands of edits over many years, and therefore also have some expectations about the interface.

We do want people to know how to turn it off, but that's what T174145 is for. Regarding the idea of a "tour" or pop-up box, I would be opposed to that, for the reasons I gave at the discussion.

Here's the problem that needs to be solved: People who use old (or otherwise underpowered) devices want to edit Wikipedia. Syntax highlighting makes the editing experience impossible or painful on some devices. A new editor opens a long/complex page with syntax highlighting enabled. Typing is very, very slow. How do you help that new editor?

Many new editors were previously IP editors, and therefore do have some expectations about the interface. Some IP editors (for whom this ticket proposes enabling by default) have made thousands of edits over many years, and therefore also have some expectations about the interface.

If IP editors care a ton about customizing their settings, they should register an account. We can't limit the rollout of features just so that IP editors will never experience any change; that would be complete folly.

Here's the problem that needs to be solved: People who use old (or otherwise underpowered) devices want to edit Wikipedia. Syntax highlighting makes the editing experience impossible or painful on some devices. A new editor opens a long/complex page with syntax highlighting enabled. Typing is very, very slow. How do you help that new editor?

I very much want to see the syntax highlighter code improved so that it doesn't slow down loading, and I hope that having this enabled by default will give the WMF some incentive to prioritize that. Loading times was an issue that you and others raised and discussed at the Village Pump discussion; the result was still consensus to proceed. Phabricator tickets are not the place for continuing or relitigating closed editorial discussions; they are for implementing the results of those discussions.

they are for implementing the results of those discussions.

That's an argument, but eventually any technical change is a developer decision. So if the developers who need to roll this out think that it would be a huge performance hit that is not tolerable to a significant part of the user base, they simply won't do it. Also CodeMirror is VERY complex optimizing is not easy. Google, Apple and others are literally paying a single developer to work on this, because they don't want to maintain that thing themselves. Do not underestimate.

I think that basically sets another requirement.. Someone needs to run a performance impact analysis.

@TheDJ, make sure to use the extension's code as it is after January 2021. We found and fixed a CPU leak that was able to block the browser for minutes when editing bigger pages. It was especially notable on pages with many very long lines. I suspect some of the performance-related concerns raised here are from users who experienced this before January 2021. That issue is fixed.

You can find flamegraphs that visualize the issue in T270317#6740027 and below.

Note that this issue was not in the upstream CodeMirror library, but in our custom wikitext highlighter.

That pair of flamegraphs show a significant improvement. Thank you for that work, @thiemowmde, and for linking it here.

I believe the other primary concerns have been about

• {{templates}} (specifically when you have typed the {{ but not closed it yet)
• extremely long pages (which are a problem for some editors even regardless of CodeMirror status).

@Sdkb, there is a gap between recognizing that have some expectations about the interface and never changing anything because of existing expectations. This would be a disruptive change. Some of the people affected by this change already have expecations about the interface; we can't change that. What we can change is how they experience the change. The most common way to manage that is to turn it on but make it easy for people to find a way to turn it off. (There are other options, like leaving it off and encouraging people to turn it on.)

In T288161#7311387, @thiemowmde wrote:

I suspect some of the performance-related concerns raised here are from users who experienced this before January 2021. That issue is fixed.

Actually I already knew about that improvement. My concerns for performance would be:

• Initial JS payload size
• reflows of content because of loading of late loading of CodeMirror (especially because the editor also changes font sizes for headings and applies bold etc). We've had years of reports where people were pointing out that when you start editing, before WikiEditor loads, that their cursor position would change and the part of the code that was visible in the wiki editor view. These issues were mostly solved, but for a long time were often experienced by users on slow connections. Adding CM adds an additional late loading stage to that 'simple' editor.

Can't we use the LocalUserCreated hook to enable the feature for new users going forward? DiscussionTools uses this for enabling email notifications (for new messages in subscribed sections) for new users. This would require adding a config option so that only interested projects enable it, so re-adding the project tag.

Change 754517 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/extensions/CodeMirror@master] Allow opting in to enable CodeMirror for new users by default

https://gerrit.wikimedia.org/r/754517

In T288161#7621912, @SD0001 wrote:

Can't we use the LocalUserCreated hook to enable the feature for new users going forward? DiscussionTools uses this for enabling email notifications (for new messages in subscribed sections) for new users. This would require adding a config option so that only interested projects enable it, so re-adding the project tag.

Two notes:

• This seems like an enwiki-specific workaround since for a missing feature (changing default preferences based on registration date) in core, not sure if extensions/CodeMirror is the best place for this or if it should be implemented somewhere else
• This has a potential to create a massive amount of rows to the enwiki settings table. Please ensure that DBA is fine with it before enabling it

This seems like an enwiki-specific workaround since for a missing feature (changing default preferences based on registration date) in core, not sure if extensions/CodeMirror is the best place for this or if it should be implemented somewhere else

LocalUserCreated hook is almost exclusively being used for setting user options, so it doesn't seem like a workaround to me. Echo does this for 5 preferences (!), DiscussionTools and Popups for 2 each; PageTriage, Thanks and Vector for one each.

Can't we use the LocalUserCreated hook to enable the feature for new users going forward?

…

• This has a potential to create a massive amount of rows to the enwiki settings table. Please ensure that DBA is fine with it before enabling it

That already happened: T286270: CodeMirror does not set a default for "usecodemirror" preference, causing user_properties bloat. Ideally we should not reintroduce what is effectively the same problem, but this went on for years before anyone noticed without any apparent performance impact. Not that that makes it okay :) Data redundancy should certainly be avoided.

In my opinion we should just enable it for everyone, and let those who don't like it simply turn it off. From the above discussion that implies T174145: Our standard highlight icon (used to enable/disable CodeMirror) cdxIconHighlight looks too much like our standard edit icon, cdxIconEdit is probably worth revisiting first.

What is the status of this task, WMF? I think it would make a real difference to editor retention and new editor engagement.

@Ganesha811: If there is anything specifically unclear with the previous comments, then please point out. The status is covered by the previous comments.

@Aklapper : to specify, is this actively being worked on by WMF staff? What timeline does the WMF see for implementation, for all IP users if not for logged-in users?

In T288161#8448595, @Ganesha811 wrote:

@Aklapper : to specify, is this actively being worked on by WMF staff? What timeline does the WMF see for implementation, for all IP users if not for logged-in users?

As can be seen from previous comments, the community asked for something , discussion ensued, a solution was not yet found.

WMF has no one allocated to figure out the details, implement it, fight with the community after it rolls out, and then refine it to the point that the community is happy ;)

@TheDJ : I see. Frankly, I don't really understand that perspective, since my understanding is that one of the WMF's primary functions is to support the community with technology and tools like this. The WMF could and should be more proactive here. I understand the community (collectively) can be challenging to deal with, but in the end we're all volunteers, while WMF staff are paid to work on things like this. It's the WMF's job (collectively) to implement MediaWiki changes and then refine them to make the community happy!

@Ganesha811: See https://www.mediawiki.org/wiki/Bug_management/Development_prioritization

As can be seen from previous comments, the community asked for something , discussion ensued, a solution was not yet found.

@TheDJ, I trust that you know how consensus works? The community reached a very clear consensus, which is to enable the syntax highlighting. A dissenting participant raising the same performance-related concerns here that they did at the discussion does not in any way nullify the result. (They also appear outdated due to the recent improvements to Syntax Highlighting.) If the WMF's goal is to avoid a "fight with the community", then disrespecting the consensus process is a very poor tactic.

On the technical issue of how to avoid creating excessive database rows, we proposed a solution above that is unlikely to ruffle feathers (turning it on for inactive editors), and no issues were raised. If that is not workable in some way, then tell us how and we can discuss further.

@Sdkb, you are addressing the wrong person. @TheDJ is not part of WMF.

@Sdkb I'm just explaining how it works, not stating that it is a good thing. I 100% agree that there should be a dedicated and funded team at the foundation that deals with these slightly more complicated requests. But there isn't, so it all depends on whichever employee decides to ignore their taskload/job and put some volunteer time into this.

Change 754517 abandoned by SD0001:

[mediawiki/extensions/CodeMirror@master] Allow opting in to enable CodeMirror for new users by default

Reason:

exacerbates user_properties table bloat issues

https://gerrit.wikimedia.org/r/754517

To take this forward, I think we need an RfC with consensus to enable this by default for all users (not just for new users – that's not happening).