Help talk:Extension:CodeMirror

differentiating between prose and references

Imo the biggest issue with naked source code is that you can't see the difference between prose and templates/references. This is more an issue if you use something like en:Template:Cite book where a reference is often multiple lines long, rather than if you use en:Template:Sfn. The current version of this feature doesn't address this, as it only highlights parameters and <ref> etc. Two options imo:
1. Reverse the colours used for parameters and <ref> etc. Ie. make parameters a pale, passive colour, and make <ref> etc., as well as the {{ and }} symbols and template call ({{Infobox country|}}, a bright, bold colour, so that it's clearer when refs and templates start and end. Idk whether it's possible to highlight the template call?
2. Highlight everything in a template (ie. between {{}}), tags, external links, and hidden comments (ie. <!--message-->) one colour, to make it clear which text is prose. I currently have this enabled at en:User:Kowal2701/common.js using a pale green (and light blue for hidden comments) Kowal2701 (talk) 15:15, 9 April 2026 (UTC)

Thanks for the feedback! Reference content is highlighted a pale green precisely to help differentiate prose from references. There is also the "Fold all <ref> tags by default" feature, which you may find helpful.

I don't know that drastic changes to the colors at this stage is an option, given we have so many years of precedent of what the colors refer to. You can however customize the colors as you so desire. The code in your common.js appears to be unrelated to CodeMirror. Are you sure you're not using a different syntax highlighter?

Text within a template call used to have a purple color (the same color as the curly brackets), but this was removed (phab:T383479). You can restore that in your personal CSS with:

.cm-mw-template {
	color: #80c;
}
/* Dark mode styles */
html.skin-theme-clientpref-night .cm-mw-template {
	color: #ff5edd;
}
@media ( prefers-color-scheme: dark ) {
	html.skin-theme-clientpref-os .cm-mw-template {
		color: #ff5edd;
	}
}

Hope this helps, — MusikAnimal ^talk 19:22, 9 April 2026 (UTC)

The one thing stopping me from using this

I often use ctrl + 0–9 keyboard shortcut to switch between tabs, where ctrl + 1 sends me to the first tab, ctrl + 2 the second tab, so on. However, with this enabled, these shortcuts do not work, and instead are overridden by the shortcuts that come with CodeMirror. Is there any way to disable this? Supertian8 (talk) 00:06, 22 April 2026 (UTC)

@Supertian8 Which browser/operating system are you using? Does using Alt instead of Ctrl work for changing tabs? It does on my machine (Chrome/Firefox on Ubuntu). Anyway, to answer the question, it is possible to disable it, but it would currently require a custom JS snippet be placed in your common.js. Let me know if you'd like me to write said snippet for you. — MusikAnimal ^talk 00:34, 22 April 2026 (UTC)

I’m on Edge on Windows. Alt does not work instead of ctrl. If you could code a snippet to fix this, that would be great. Supertian8 (talk) 11:43, 23 April 2026 (UTC)

CodeMirror preferences

In the section "CodeMirror preferences" please change

• To open the preferences panel, press Ctrl+⇧ Shift+, (or ⌘ Command+⇧ Shift+, on macOS)
• to
• To open the preferences panel while using the editor, press Ctrl+⇧ Shift+, (or ⌘ Command+⇧ Shift+, on macOS).

The key presses are futile outside of the editor. Johnjbarton (talk) 01:57, 26 April 2026 (UTC)

Done. Note however all of the documentation pertains to the editor. If the editor is not open, CodeMirror is not being used. — MusikAnimal ^talk 03:45, 26 April 2026 (UTC)

Please add a preference to disable "auto indentation"

Indentation in general makes little sense outside the "code" environments (Lua/JS/some templates). But since recently, when I press Enter and the cursor is before a space, some kind of "auto indentation" takes places and adds an aditional unexpected space. Please consider adding a preference to disable the "auto indentation" feature. Thanks in advance,

this is the result of pressing "Enter" 5 times in front of a space. Each line gets an additional space

Ignacio Rodríguez (talk) 17:52, 27 April 2026 (UTC)

This actually sounds like a bug. It's supposed to keep the same level of indentation as the line above (phab:T389328). I have filed phab:T424575. Thanks for reporting, — MusikAnimal ^talk 20:02, 27 April 2026 (UTC)

Gadget gets turned off in preferences

The gadget keeps tuning itself off in the global preferences, the box unchecks every time I open a new page or refresh. It seems to stay on if I set a local preference. Is that a known bug? Trooper57 (talk) 22:53, 11 June 2026 (UTC)

I just reported the same bug yesterday: Phab:T428887. 析石父 (talk) 08:29, 12 June 2026 (UTC)

Cycle through lint errors by type

In the status bar, there are red, yellow, and blue buttons. It'd be nice to be able to cycle through each type separately: so, for example, the blue button takes you from one blue error to another. It's usually one type that I'm fixing at a time en masse. pon_or (talk) 13:17, 6 July 2026 (UTC)

Ignore some lint errors

I've been fixing a lot of lint errors lately. When a page has colored tables and stuff, there will be tens to hundreds of errors that are virtually impossible to fix, but making the ones you want to fix much harder to find. Is it possible to ignore some error types somehow? Thinking of "Background color inline style rule exists without a corresponding text color", which come from hundreds of little templates, or bgcolor=... in table cells, i.e. "obsolete-attr" errors, and similar. pon_or (talk) 13:24, 6 July 2026 (UTC)

WikiLint errors such as "obsolete-attr" can be ignored with inline comments. 析石父 (talk) 17:54, 13 July 2026 (UTC)

True, but it doesn't help when you're fixing lint errors on hundreds of pages. A global setting, even a piece of js code injected into the page would be a much better option. pon_or (talk) 18:18, 13 July 2026 (UTC)

Please refer to the JS documentation for code snippets. 析石父 (talk) 20:44, 13 July 2026 (UTC)

Thank you very much, @析石父. That worked, but now I only know how to use it for "WikiLint" errors. What I've just learned is that there are also "Parsoid" errors reported in the editor, which do not come with a name (e.g. obsolete-attr). Is there any way to deal with them, you know? Here's an example of the two: https://test.wikipedia.org/wiki/Linterrortypes pon_or (talk) 10:36, 14 July 2026 (UTC)

No, that is not supported yet. 析石父 (talk) 11:49, 16 July 2026 (UTC)

Regression in link insertion feature ?

Hello, I noticed a few days ago (on wikt:fr:, but I can reproduce that behavior on s:fr: and w:fr ) that "link insertion" suddenly ceased to work reliably in CodeMirror:

Steps :

• I edit the wikicode of an article, with CodeMirror enabled.
• I select a word, then press ctrl + k, → it still opens the link insertion popup dialog
• but when I press the button to insert the link in this dialog nothing happens in the wikicode (it doesn't add the wikilink syntax). No error are displayed in the browser's console (latest firefox).

In contrast, if I disable CodeMirror, the equivalent ctrl + k shortcut is still working in the WikiEditor.

Strangely:

• If I keep CodeMirror enabled, and first click the WikiEditor's toolbar "link" icon-button, it opens the same popup link insertion dialog (which works fine and would add a link if requested, but just opening the dialog is necessary, so inserting a link, cancelling or closing the popup dialog does not seem to be a decisive factor),
• Then if use the ctrl + k key shortcut, the dialog will work correctly again with CodeMirror (until CodeMirror is disabled or the page reloaded)

Has anyone else experienced this problem? --FoeNyx (talk) 13:18, 13 July 2026 (UTC)

I believe it is related to recent WikiEditor change. 析石父 (talk) 17:55, 13 July 2026 (UTC)

Perhaps. Seems pon_or mentioned this thread on the phabricator ticket (Phab:T296396) linked in that change, so we will see if they think it's related (else I should probably open a new ticket I guess). --FoeNyx (talk) 05:59, 14 July 2026 (UTC)

The ctrl + k is currently working again. --FoeNyx (talk) 17:18, 23 July 2026 (UTC)

Use on Safari on iOS - backspace issue

Somewhat of an odd issue… I often do editing in my phone (iOS) through my mobile browser in desktop mode. When I do so however, with syntax highlighting turned on, often pressing backspace actually removes two characters at once, not just one as expected. This usually happens when I’m somewhat rapidly pressing the key, and usually around non-alphanumeric characters (eg. ref tags or templates). Any idea if this is a bug, or a setting that I haven’t found? Danners430 (talk) 00:05, 16 July 2026 (UTC)

That sounds like a bug. It will be helpful if you could provide reliable steps to reproduce.

However, please be aware that the CodeMirror extension is not yet fully supported on mobile devices. 析石父 (talk) 11:54, 16 July 2026 (UTC)

Stealing focus on preview refresh

I noticed (on wikt:fr & s:fr, & here, but not on w:fr atm) that if CodeMirror and the automatic page preview side panel are enabled, when the preview refresh (on load or slightly after a change), the focus change back to the CodeMirror edit area (especially annoying when you are already typing your change summary, or when you are using the "insert link" popup). Has someone else experienced the same behaviour? --FoeNyx (talk) 17:22, 23 July 2026 (UTC)

@FoeNyx Thanks for the bug report. The intention was for the autofocus to happen after using live preview, but indeed the interaction with Realtime Preview is an unwanted side effect. We'll get this fixed. — MusikAnimal ^talk 22:18, 23 July 2026 (UTC)

Fixed with gerrit:1315283, but at this point we'll have to wait until Monday (UTC) to backport the change. — MusikAnimal ^talk 05:16, 24 July 2026 (UTC)

Thanks a lot. --FoeNyx (talk) 07:23, 24 July 2026 (UTC)

section tags on Wikisource in French

On the Wikisource in French, seems there are some hooks on the WikiEditor (I don't know the exact mechanism at play here) that convert <section> tags to a "## section-name ##" syntax in the main text area on load, and back to the <section> syntax on save.

But when I open a page that contains some <section> tag tags on s:fr: with CodeMirror enabled, the loading hook changes the section tags to "## section-name ##", but on save it does not change it back to the <section> tag syntax, thus silently breaking the layout. (luckily loading+saving, with CodeMirror disabled, fixes it back, but one has to notice that it had been broken in the first place, as one could simply be editing to header/footer textareas).

Does it seems like a CodeMirror bug, or more like a need for s:fr: to do some adaptations to make their workflow works with CodeMirror? --FoeNyx (talk) 12:30, 25 July 2026 (UTC)

It looks like a gadget bug, although I do not know which gadget is related. 析石父 (talk) 08:01, 27 July 2026 (UTC)

I see, then I'll bring this issue up on that project. Thank you. --FoeNyx (talk) 08:34, 27 July 2026 (UTC)

Discussion at w:Wikipedia:Village pump (technical)#Enabling syntax highlighting by default for newcomers

 You are invited to join the discussion at w:Wikipedia:Village pump (technical)#Enabling syntax highlighting by default for newcomers. Sdkb-WMF ^talk 14:15, 7 August 2026 (UTC)

Support for Module code in Wikimarkup

Are there any plans to add support for syntax highlighting of module code (using #invoke) in wikimarkup view? Right now parameter names in this are rendered the same as plaintext... Zackmann08 (talk) 04:15, 20 September 2026 (UTC)

Yes, we plan to implement this, but probably after the upcoming release of MW 1.47. In the meantime, you can test it at my GitHub page which shows a proof of concept. 析石父 (talk) 11:21, 4 October 2026 (UTC)

That is AWESOME!!!!! Thanks fro the response! Zackmann08 (talk) 16:11, 4 October 2026 (UTC)

I have created Phab:T441565 and started working on it. 析石父 (talk) 11:50, 18 October 2026 (UTC)

Enabling CodeMirror by default on all WMF wikis for newbies

You can learn more at phab:T440077. This change would effect only unregistered users and newly created users. As always, users will still be able to toggle off syntax highlighting. If there are questions or concerns, please let us know here. Thank you! — MusikAnimal ^talk 16:33, 8 October 2026 (UTC)

There is a concern at enwiki. I propose immediate reversion so that people who had accounts prior to 15 October have the syntax highlighting w:WYSIWYG set to opt-in instead of opt-out. If you wish to propose making it opt-out on enwiki, then please start an RfC on enwiki. Currently the rough consensus appears to be strongly in favour of opt-in, not opt-out. Obstructing plain-text editing should not be imposed as opt-out without prior consensus.

Personally I would also recommend making this opt-in for post-15-October new accounts on enwiki, but that's a complementary question. Boud (talk) 11:57, 15 October 2026 (UTC)

Just adding a @MusikAnimal: for notification. Boud (talk) 11:58, 15 October 2026 (UTC)

As you've probably already seen, the issue on English Wikipedia was due to a misconfiguration on my part, and has now been fixed. My apologies!

There was already a formal RfC for English Wikipedia some years ago. The consensus was to only enable to for new accounts and unregistered users, which now after I've fixed the configuration, is what English Wikipedia is using. The well-known fact is that editors who are used to a specific environment should not be forced to a completely new one. On the flip side however, new users who are born into CodeMirror will become accustomed to it and likewise probably will never turn it off. It's impossible to speak for those users who haven't started editing, but English Wikipedia agreed new users should get CodeMirror by default, so we're trying to do the same globally now. — MusikAnimal ^talk 19:45, 15 October 2026 (UTC)

Thanks for the fast fix!

I suggest that you link that that some-years-ago-RfC in the official announcements. That would help greatly in transparency. While you're clearly an active enwiki community member, there is still presumably some level of "WMF" participation in the decision-making pipeline, and any small concrete steps that can be done to re-establish trust in WMF-community relations would help - even if this is not directly about WMF employees and their relation to WMF management. For this discussion I'm happy to take your assertion of the RfC on good faith, but for a broader audience, better give the evidence than just make the assertion.

Personally I think that giving non-plain-text editing by default to new users is a form of miseducation, but I'm unlikely to open a counter-RfC, nor get anywhere remotely needing w:WP:DROPSTICK. Boud (talk) 20:35, 15 October 2026 (UTC)

The RfC is mentioned in the linked Phab task and in the recent follow-up straw proposal. The only opposition we received was due to performance problems, which have been addressed. And nope, CodeMirror is 100% volunteer-written and maintained, although we've had the blessings of the Editing team in our various endeavours. @Sdkb started the original RfC as a volunteer, and the straw proposal as staff (being a Movement Comms specialist), but there's no one calling the shots here except for our own users such as you. What happened today was 100% my fault and an oversight in deploying a configuration change.

Worth mentioning is the eventual adoption of Community Configuration in CodeMirror (phab:T440078). After this is done, admins on each wiki will have full control over the default settings. Not only whether CodeMirror is on or off by default, but also which features are on by default. All settings are still configurable on a per-user basis, by design. — MusikAnimal ^talk 21:48, 15 October 2026 (UTC)

Enable CodeMirror by default on all wikis for myself

I edit a lot of wikis. How do I synchronize my CodeMirror preferences (enabling/disabling included) without having to click through all 900 wikis or make 900 API calls? NguoiDungKhongDinhDanh 17:24, 13 October 2026 (UTC)

It's supposed to automatically be a global preference, but I noticed myself that stopped working recently… I will have a look and try to get it fixed. — MusikAnimal ^talk 17:49, 13 October 2026 (UTC)

I know what it is. The default value for English Wikipedia was changed to true. The way preferences (and global preferences) work is that when saving, if the value is the same as the default, the row gets deleted. So if you enable CodeMirror on English Wikipedia, it will see it matches the local default, and thus your global preference is deleted.

This hopefully won't be a problem in a few weeks; Per above, we're trying to enable CodeMirror by default on all wikis.

This does however still point to an actual bug in MediaWiki. I'm going to file a task and try to get it fixed. — MusikAnimal ^talk 18:50, 13 October 2026 (UTC)