Help talk:Extension:CodeMirror

From mediawiki.org

This is the talk page for discussing improvements to Help:Extension:CodeMirror. Put new text under old text. Click here to start a new topic. Please sign and date your posts by typing four tildes (~~~~). Be polite, and welcoming to new users Assume good faith Avoid personal attacks

Archives

Recently, with Syntax Highlighting enabled, expansion of the editing pane seems to be inaccessible; no scroll bar appears when the text reaches the bottom of the window, and there is no expansion icon to increase its area. Instead, the editing pane starts expanding downwards, clipping through the Footer, the Proofreading Status buttons, and the Edit Summary UI. All other page functions still work as intended, but visually, this issue is a bit disruptive. I've (reluctantly) disabled the tool for now, and the scroll bar functionality is back. Just bringing attention to this—hopefully it can be solved at some point! I'd love to reenable the tool.

—SpikeShroom (talk) 15:04, 6 February 2026 (UTC) Reply

A relevant patch has been submitted and is waiting for code review. 析石父 (talk) 06:13, 14 February 2026 (UTC) Reply

I deal with large articles and just tested the Improved Syntax Highlighting beta feature this evening. It appears, at least on Opera GX, that the find tool (ctrl+F) does not work properly in the editing pane with the feature enabled. The only other issue, to me at least, is that the dark green text for references does not particularly highlight them to the editor. I feel that highlighted references should be more prominent; long citations in prose are the main reason I turned the feature on, to be able to quickly differentiate between prose and hidden text. Still great work! Mb2437 (talk) 22:47, 13 February 2026 (UTC) Reply

@Mb2437 The browser Ctrl-F won't work when searching within the CodeMirror document. That is (or was) a hard requirement for performance, but I have been doing some thinking and may be able to come up with a solution. In the meantime, it should be putting initial focus on the editor so that Ctrl-F works when searching the wikitext. If it is not for you, make sure "Put initial focus on the editor" is set in your CodeMirror preferences.

As for highlighting references, it took a while to get the colors just right where they are still WCAG-compliant. Feel free to adjust the colors yourself (you can use Help:Extension:CodeMirror#Color and style customization as a guide). If you come with something you like, please share and we'll see if we can get it added to the code :)

Also, if you weren't aware, you might be interested in the "Fold all <ref> tags by default" feature, which is also available in the preferences dialog.

Hope this helps, — MusikAnimal ^talk 23:58, 6 March 2026 (UTC) Reply

Hello guys, thx a lot for your work!

I tried Extended CM, but I needed to disable it because after coding a bullet list (see here, the diff after disabling), nothing were published, not even the ":" and the <CR> before the list, just nothing (as if i didn't do any change)...
Not really sure this comes from the bulleted list, but I just can report here what I've done.
Wishes, — jeep (j33p) ॐ 13:10, 6 March 2026 (UTC) Reply

@J33p The only thing that comes to mind is perhaps you have a conflicting script or gadget. I had a look at your personal JS and nothing stood out, but just to be sure: Can you try again in safe mode? I.e [1] for the article you mentioned.

Also if you could, check if there are any JavaScript errors. See w:en:WP:JSERROR for instructions, and Help:Locating broken scripts for further tips.

Best, — MusikAnimal ^talk 22:13, 6 March 2026 (UTC) Reply

Thx taking time to have a glance at my conf' @MusikAnimal !
I red carefully your answer and i will check all that, ASAP.
I promise I'll come back as of I have a clue.
Also thanks for the links !
Regards, — jeep (j33p) ॐ 11:13, 7 March 2026 (UTC) Reply

I decided to test out this gadget again, but I immediately ran into problems. I remembered to enable it in two different places (see above), which seems like an anti-pattern. I was hoping that would have been fixed by now (and maybe it will, once it is no longer a beta feature?).

Then I went to use https://en.wikipedia.org/wiki/Special:ExpandTemplates and found that I was unable to drag the bottom right corner of any text boxes (input or output) to expand them, which is a feature that I use all the time. If I disable this CodeMirror syntax highlighter and re-enable the normal gadget, I can expand the windows just fine.

When I go to https://en.wikipedia.org/wiki/Special:LintErrors/obsolete-tag?wpNamespaceRestrictions=5&tag=strike and click on the "edit" link for one of the pages, the page opens in edit mode, but the wikitext in the edit box jumps up to the top of the page source instead of jumping to the problem tag in question and highlighting it, as it does when I do not have this beta feature enabled. I thought "no problem, I'll just click the LintHint script box to get the list of errors, then hit the down arrow to jump to the problem tag. The wikitext in the edit window does not move. These problems make this syntax highlighter a lot less useful for fixing Linter errors than it should be, which is the whole point of why I might use it.

I hope that these bugs can be fixed. I'll come back in a while to try it again. Feel free to ping me with answers or suggestions for how to fix these problems on my end. Jonesey95 (talk) 04:31, 12 March 2026 (UTC) Reply

Hello again!

I remembered to enable it in two different places – that should be fixed, following gerrit:1187966 from last September. I'm not sure why it didn't work for you, but indeed it certainly won't be an issue after CodeMirror 6 is promoted from Beta, which is slated to happen in May 2026.

Incidentally, the other problems you mention have fixes in the works right now. The issue with standalone CodeMirror editor not being expandable is tracked at phab:T407203, and the the Special:LintErrors linking issue is phab:T418329. Both fixes should hopefully go live next week :)

I'll just click the LintHint script box to get the list of errors, then hit the down arrow to jump to the problem tag. The wikitext in the edit window does not move. – The LintHint script evidently is not compatible with CodeMirror (you'll have to talk to the maintainer), but perhaps you don't need it because proper Parsoid linter errors are now surfaced in CodeMirror itself! Linting is disabled by default for wikitext. Go to your CodeMirror preferences and select "Lint the code" to try it out. You can click on the icons in the status bar to jump to the next errors. Right now, both Extension:Linter errors (i.e. Parsoid) and our own linter are mixed, but we plan to allow you to select which linters you want (phab:T408729). That is fairly high on the to-do list, after we get this thing deployed once and for all. — MusikAnimal ^talk 05:31, 12 March 2026 (UTC) Reply

Thanks for the responses, and I'm glad that these issues are being worked on. I will try this new syntax highlighter again later in 2026 to see if it will work for pursuing and fixing MediaWiki Linter errors. Jonesey95 (talk) 11:44, 12 March 2026 (UTC) Reply

I recenlty subscribed to tech news; I found it on someone's discussion page. And they just sent info about CodeMirror coming out of beta. I have edited Wikipedia for 15 years, I only use WikiCode, and I just now found that there is syntax highlighting.

This feature should be more prominent if it's part of MediaWiki core. I didn't even know there is advanced menu in the toolbar where you can enable this feature.

Just my feedback, a lot of editors may also not know that this great feature exists. Jcubic (talk) 20:04, 16 March 2026 (UTC) Reply

It will be a bit less hidden, I hope, with the rollout of CodeMirror 6. There's a checkbox in the "Editing" section of preferences that advertises it, and in the 2010 editor, you'll see a "Syntax" button instead of just the icon as it was previously in CodeMirror 5. At any rate, this is not part of MediaWiki Core, for the record. — MusikAnimal ^talk 22:25, 30 March 2026 (UTC) Reply

In the second paragraph on CodeMirror preferences, the ⧼codemirror-prefs-panel-advanced⧽ is not interpreted. Please correct with true value or removing the parenthesis.Thanks. -- Christian 🇫🇷 FR 🚨 (talk) 16:25, 30 March 2026 (UTC) Reply

Yes Done Thank you! — MusikAnimal ^talk 22:24, 30 March 2026 (UTC) Reply

Page https://www.mediawiki.org/wiki/Extension:CodeMirror is referencing a functionality bidiIsolation which is not described on this page. Why ? Thanks. -- Christian 🇫🇷 FR 🚨 (talk) 17:51, 30 March 2026 (UTC) Reply

It is a feature that was never finished and needs to be rewritten. — MusikAnimal ^talk 22:22, 30 March 2026 (UTC) Reply

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) Reply

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) Reply

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) Reply

@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) Reply

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) Reply

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) Reply

Yes 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) Reply

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,

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

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) Reply

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) Reply

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

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) Reply

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) Reply

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

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) Reply

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

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) Reply

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

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) Reply

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

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) Reply

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

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) Reply

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) Reply

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) Reply

@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) Reply

Yes 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) Reply

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

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) Reply

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

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

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) Reply

Retrieved from "https://www.mediawiki.org/w/index.php?title=Help_talk:Extension:CodeMirror&oldid=8548612"