Page MenuHomePhabricator

Syntax highlight should not be in sync between wikitext and non-wikitext pages
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Go to a wikitext page on rowiki and disable syntax highlighting.
  • Go to a module on the same wiki and check if syntax highlighting is enabled

What happens?:
Syntax highlighting is disabled

What should have happened instead?:
Syntax Highlighting should remain enabled for modules. More precisely, it should have different values remembered (per content type? namespace? Not sure...)

Other information (browser name/version, screenshots, etc.):
This is happening since 2026, we're probably talking about a regression.

Event Timeline

Before these were two extensions (CodeMirror and CodeEditor). With the "Improved syntax highlighting" Beta feature, you only get CodeMirror in an effort to provide a consistent editing experience across all content models and namespaces. The idea is all code-related features also can apply to wikitext, so we keep all of it under roof for easier maintenance and user convenience.

That said, it is certainly not uncommon for users to want to treat proper code differently than wikitext, which is why non-wikitext gets different default values for CodeMirror features (i.e. "code folding", "autocompletion", etc.). We don't currently however have a means to do the same for syntax highlighting itself, nor are the individual feature preferences remembered differently for different content models, etc.

This might need careful thought. There is an actual preference in Special:Preferences for "Enable syntax highlighting" that refers to all content models. I suppose it could be worth it to add a dependent preference, "Only add syntax highlighting to code, not wikitext". But then what do we do with the CodeMirror sub-preferences for the individual features? Do they also get separated for wikitext and non-wikitext, or should they be shared? I suppose separate, too. I know for me at least, I like line wrapping in the mainspace and no line wrapping everywhere else.

Another idea is to look into the concept of "CodeMirror without syntax highlighting". That way you can get the various other features such as line numbering and multiple cursors without also having to have syntax highlighting. If we did it that way, we can make syntax highlighting itself a separate "CodeMirror feature". Then we only need to make all CM features dependent on content models, and boom, everybody wins. The issue there is how complicated the nomenclature would become. For example, the preferences dialog in CodeMirror is called "Syntax highlighting preferences", and one of those preferences would be "Syntax highlighting" itself. And heck, the button itself in WikiEditor says "Syntax". I think it might seem odd to turn that on and it not provide syntax highlighting (though the user would have to configure it that way themselves, so maybe it's okay?).

Hopefully I'm making sense. It's all quite complicated, which is why we wanted to keep it simple and have the same preferences honoured everywhere. After all, as it stands now you'd only need to click one button to toggle the syntax highlighting on and off.

We have a goal to ship CodeMirror as a replacement for CodeEditor with MW 1.46 (May–June 2026). I wonder if this task would be a blocker to that.

But then what do we do with the CodeMirror sub-preferences for the individual features? Do they also get separated for wikitext and non-wikitext, or should they be shared? I suppose separate, too. I know for me at least, I like line wrapping in the mainspace and no line wrapping everywhere else.

IMO, the final goal should be to match an IDE's features. JetBrain's IDEs all offer different editor settings per language. For MW, the equivalent would be per content model I believe, so my answer would be "yes".

We have a goal to ship CodeMirror as a replacement for CodeEditor with MW 1.46 (May–June 2026). I wonder if this task would be a blocker to that.

As much as I would very much like to have a bunch of IDE-like features, realistically speaking, at most my original requirement (to enable syntax highlighting per NS) could be considered as a potential blocker. The individual settings per language/content model/namespace/whatever ar just nice to haves.

As much as I would very much like to have a bunch of IDE-like features, realistically speaking, at most my original requirement (to enable syntax highlighting per NS) could be considered as a potential blocker. The individual settings per language/content model/namespace/whatever ar just nice to haves.

May I ask why you prefer syntax highlighting for code, but not for wikitext? I mean, from the perspective of someone who writes code (which I assume you are if you edit Lua modules). I totally get it if folks don't want syntax highlighting, but the impression is usually they'd want it everywhere or nowhere. I guess what I'm asking is what, if anything, about CodeMirror + wikitext is not working for you, in hopes we can fix that instead?

As another example, SyntaxHighlight provides static highlighting of quite a few languages including MediaWiki wikitext. Wikitext is treated just like any other language and is always highlighted.

In the end we just want to make sure no one gets pissed off when CodeEditor is replaced, hehe. Hopefully most will be wowed! I realize the world of having wikitext syntax highlighting vs. CodeEditor has ruled for a decade or more now, so folks are just used to it being that way. But could it just be the usual change aversion?


Anyway, it occurred to me we can repurpose the existing usecodemirror preference and adjust the UI at Special:Preferences so that when selected, the user is given a TagMultiselect widget to choose which content models or namespaces to apply the preference to. The initial true/false value remains for minimal storage consumption unless further granularity is provided via the multiselect. That would work out nicely, and toggling via the "Syntax" button in WikiEditor in whatever namespace/content-model would accomplish the same as adjusting it in Special:Preferences. So, I do see a path forward, but I still want to make sure we understand the use-case :)

I had already given thought to a desire to change the individual features on a per-content-model basis, as mentioned above. I had figured that would have been the main headache, and indeed is one I've experienced myself.

For example, the preferences dialog in CodeMirror is called "Syntax highlighting preferences", and one of those preferences would be "Syntax highlighting" itself. And heck, the button itself in WikiEditor says "Syntax". I think it might seem odd to turn that on and it not provide syntax highlighting (though the user would have to configure it that way themselves, so maybe it's okay?).

The current situation is already odd. It is not obvious at all that if you want linting in wikitext, you have to enable syntax highlighting.

May I ask why you prefer syntax highlighting for code, but not for wikitext? I mean, from the perspective of someone who writes code (which I assume you are if you edit Lua modules). I totally get it if folks don't want syntax highlighting, but the impression is usually they'd want it everywhere or nowhere.

In my case, I didn't use Code mirror for wikitext before CodeMirror 6 and only started using it after the addition of linting because I don't like the colors it uses and I would rather not enable syntax highlighting than enable it with colors I dislike.

May I ask why you prefer syntax highlighting for code, but not for wikitext?

  1. Way too colorful. Even the simplest articles have 7 different colors, while modules are usually limited to 4.
  2. Visibly slowing the experience for large pages - pressing End on a large page (e.g. [[:w:ro:Metroul_din_București]]) on my computer leads to a visible delay until the highlighting catches up
  3. Wikitext code (even in templates) is often not indented in a consistent manner; colors make it even harder to follow (at least for me)
  4. Has some features which simply look weird (line numbers every n visible lines due to wrapping)

I would love *some* of the features, such as bracket pair hightlighting even in wikitext.

The current situation is already odd. It is not obvious at all that if you want linting in wikitext, you have to enable syntax highlighting.

This works exactly like CodeEditor. Ace syntax highlighting is required for linting.

The current situation is already odd. It is not obvious at all that if you want linting in wikitext, you have to enable syntax highlighting.

This works exactly like CodeEditor. Ace syntax highlighting is required for linting.

Yes, but you do not need to activate a preference called "syntax highlighting" to activate it in ace. Maybe I should have used quotes to make it clear that I was only speaking about the name of the preference option.

This is great feedback, thank you!

Starting with some direct replies:

In my case, I didn't use Code mirror for wikitext before CodeMirror 6 and only started using it after the addition of linting because I don't like the colors it uses and I would rather not enable syntax highlighting than enable it with colors I dislike.

Way too colorful. Even the simplest articles have 7 different colors, while modules are usually limited to 4.

Themes will arrive eventually (T163533). Until then, if you want a minimalist experience with respect to colors, you could try colorblind mode. Note also all colors can be customized with personal (or site-wide) CSS, as documented at https://www.mediawiki.org/wiki/Help:Extension:CodeMirror#Color_and_style_customization

I will add that the current colors for both normal and colorblind-mode have been carefully selected to be WCAG-compliant. That is, they shouldn't be too hard to discern from one another. It just so happens wikitext is a very verbose language with lots of different syntax structures, so it invites more colors! Of course people will have opinions, though :) On some Wikisources, you used to see a sea of purple until T383479: Consider removing purple color from template text was resolved. I hope with the eventual advent of themes, and perhaps even some CommunityConfiguration-Adoption, the standard experience will work for most all users.

This works exactly like CodeEditor. Ace syntax highlighting is required for linting.

Yes, but you do not need to activate a preference called "syntax highlighting" to activate it in ace. Maybe I should have used quotes to make it clear that I was only speaking about the name of the preference option.

To be clear, what you see with "Improved Syntax Highlighting" is not Ace, but CodeMirror. Which leads to my next point…

Another idea is to look into the concept of "CodeMirror without syntax highlighting". That way you can get the various other features such as line numbering and multiple cursors without also having to have syntax highlighting.

I think this is starting to sound more like the right approach. But it opens the can of worms of CodeMirror being a proper standalone editor, say the "2026 editor". We need to more prominently offer toggle buttons for various features, with "Syntax" highlighting being one of them. That, or come up with a more generic in-editor name for the extension that adds a bunch of editing features, but without making it sound too much like a different "editor", if that makes sense. Unless of course we formally offer it as a different editor!

I'm not sure about things like linting, specifically, but surely we can do bracket matching, line numbering, and multiple cursors without actually having syntax highlighting. The issue then is separation of features from a user perspective (with special attention to newbs!). Right now the "Syntax" button is a convenient way to basically just toggle all the "fanciness" on and off. I'd love for a "2026 editor" to come to fruition, but it needs close cooperation with the Editing team and most certainly we won't have all the aforementioned done by this coming May.


Keep the feedback coming!

Unless of course we formally offer it as a different editor!

I feel that we went into too many details and we risk waking up some monsters. :)

Maybe it'll help to go back to the user requirements expressed so far and group them:

  1. Syntax highlighting should be available for all editors (modules, javascript, css, wikitext, wikitext-via-VE) - this seems resolved
  2. Syntax highlighting colors should be configurable without writing CSS - covered in T163533
  3. Syntax highlighting should be separated from any other IDE-like features such as linting, bracket matching, line numbering and users should have granular control over these features
  4. IDE-like features should be enabled per namespace or content type and users should have granular control over the pages where each is enabled
  5. Users should have some control over IDE-like features directly from the editor toolbar

Did I miss anything?

I personally consider IDE-like features as "advanced", so enabling and disabling them should only be possible in the user settings, so I would not implement requirement 5. If you keep the IDE-like features in the preferences, they should be enabled by default so new users can take advantage of them.

However, if you decide to implement requirement 5, it seems easy enough in the wikitext editor: just display another toolbar (similar to the "advanced" toolbar) with some (few) checkboxes. These can be kept in sync with the user preferences and the user could access additional configurations from their preferences. Not sure if this solution would work for the 2010 wikitext editor.

Brilliant summary!

  1. +1
  2. Dev notes: we're actually not far from making T163533 more or less doable. We just need to tweak the tokens, define a few parents here and there, and we will have a plethora of themes to offer from upstream libs.
  3. I just don't think it will happen before MW 1.46 (May-June), if that matters. I'd love to tackle it soon afterwards.
  4. This can be done more quickly, but I know it is less desired in the context of this task. It may serve as preliminary work towards (3) so perhaps its where we should start.
  5. I envisioned it much as you have, and with just the basics.

Speaking from a 2010 editor perspective, the additional buttons could go under the existing "Advanced" section. There seems to be room for it. We also need to advertise this not just as "syntax highlighting" but also "editing tools"… no? So the main preference at Special:Preferences could be renamed to i.e. "Enable syntax highlighting and advanced editing tools". Then we've got our in-editor preference panel, which I guess could be "Syntax highlighting and editing preferences"? Then of course the "Syntax" button itself, which I guess toggles only the syntax highlighting (?).

All of this is doable but will take time, but overall it sounds like a step in the right direction.

I have filed T419339: Add "no syntax highlighting" as an available theme within CodeMirror and T419337: Allow CodeMirror preferences to differ between wikitext and non-wikitext based on the conversation here.

Is it fair to repurpose this task as "Allow ability to turn CodeMirror off by content model [and/or namespace]"? Meaning all features:

… we can repurpose the existing usecodemirror preference and adjust the UI at Special:Preferences so that when selected, the user is given a TagMultiselect widget to choose which content models or namespaces to apply the preference to. The initial true/false value remains for minimal storage consumption unless further granularity is provided via the multiselect. That would work out nicely, and toggling via the "Syntax" button in WikiEditor in whatever namespace/content-model would accomplish the same as adjusting it in Special:Preferences.

This can be done but still takes time and I'd personally like to see a bit more justification. Turning syntax highlighting on/off now is only one click away, after all. Again if we do the above, it'd be only to hold us off until T419339 comes around. I assume we don't need both, so there's a cost in confusing folks with the "kill it all" switch versus waiting it out, if that makes sense.

MusikAnimal changed the task status from Open to In Progress.Wed, Apr 22, 4:48 PM
MusikAnimal claimed this task.

We've heard enough. I will add a separate preference for toggling CodeMirror entirely on non-wikitext, default enabled.

MusikAnimal renamed this task from Syntax highlight should not be in sync between modules and wikitext pages to Syntax highlight should not be in sync between wikitext and non-wikitext pages.Wed, Apr 22, 6:01 PM
MusikAnimal updated the task description. (Show Details)

Change #1276424 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/CodeMirror@master] Allow the main 'usecodemirror' preference to use a mode ID

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

Change #1277249 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/CodeMirror@master] Split preferences into two pairs of user options for (non-)wikitext

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

Change #1276424 abandoned by MusikAnimal:

[mediawiki/extensions/CodeMirror@master] Allow the main 'usecodemirror' preference to use a mode ID

Reason:

superseded by I09d19567a228e6049f4a94ef312ce8becfb5f0ad

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

Change #1277249 merged by jenkins-bot:

[mediawiki/extensions/CodeMirror@master] Split preferences into two pairs of user options for (non-)wikitext

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

MusikAnimal moved this task from Improvement to Done on the MediaWiki-extensions-CodeMirror board.

Preferences are now split entirely between wikitext and non-wikitext. This pertains to both the main preference (usecodemirror and usecodemirror-code) as well as CodeMirror preferences (codemirror-preferences and codemirror-preferences-code).

I also made both of these preferences always save as a global preference. I am assuming this is what users will almost always want, but should there be concerns, we can adjust it to honour local exceptions, and I guess add a "Save preferences globally" checkbox or something to the CodeMirror preferences dialog (as these prefs aren't exposed in Special:GlobalPreferences). Further down the road, we might expose the CM preferences in the Special forms, but it will be tricky and deserve a strong use-case.