Extension talk:CodeMirror

I know it may be too late, but couldn’t we use native DOM objects in frontend hooks instead of jQuery objects? jQuery is a quite sloppy interface: it tries to handle everything uniformly, even though it’s impossible – one naturally has to handle elements and collections of elements differently ("elements" are jQuery objects with zero or one HTML element, "collections" are jQuery objects with potentially more than one element), just like different types of elements (e.g. jQuery provides a .val() method on all jQuery objects, even though it makes sense only on form elements). If you see that the ext.CodeMirror.initialize gives you a jQuery object, you don’t know what you actually get. If it gives you an HTMLTextAreaElement, you know that

• it’s one element, not zero and not more,
• and it has all the properties a text area has (value, read-only state etc.).

Given the HTMLTextAreaElement, you can always wrap it in a jQuery object if it’s more convenient, but unwrapping is not possible in a statically-provably safe way. —Tacsipacsi (talk) 19:19, 19 November 2024 (UTC) Reply

It's funny you mention this. As I writing more docs the other day, I had the same thought! I chose jQuery for frontend hooks pretty much only because so many other hooks (in Core and extensions) do the same. There's something to be said about consistency, but I do regret the decision nonetheless for the reasons you state, and indeed I'm afraid it's too late to change it now. Even in the CodeMirror extension itself, we more often than not need to access the HTMLTextAreaElement, so it would make things easier to work internally to rid of jQuery altogether!

It's only tentative right now, but I believe ext.CodeMirror.switch (documented to work only with WikiEditor) will be deprecated in favor of a new hook, ext.CodeMirror.toggle, which is fired regardless of where what editor CodeMirror is integrated with. I had already planned to not fire the hook with a jQuery object, but instead the CodeMirror instance. So at least we're head in that no-jQuery direction, I guess. — MusikAnimal ^talk 01:46, 26 November 2024 (UTC) Reply

This is a very minor point, but maybe we should change the image on this page. It's 8 years old, and it doesn't do justice to what CM can do anymore.

What I'm wondering, though, is, should it be replaced with a CM5 or CM6 screenshot? As CM6 is the "right" version and will replace completely CM5 in not too long, but most people don't have CM6 yet. — Alien 3
3 3 17:33, 15 April 2025 (UTC) Reply

Yes, it should be replaced, and should show CM6, while the existing image can remain at Extension:CodeMirror/5.

I'll get the image updated soon, unless someone beats me to it ;) — MusikAnimal ^talk 19:30, 16 April 2025 (UTC) Reply

I hope the one I used is OK. Tactica (talk) 14:16, 4 May 2025 (UTC) Reply

Looks great, thank you! :) — MusikAnimal ^talk 19:19, 6 May 2025 (UTC) Reply

I'm using CodeMirror 6.0.0 (3def77c, built on Feb 25, 2025) with MW 1.43.1 and Vector 2022. If I hit the preview button in the editor while syntax highlighing is enabled, the view first switches to the beginning of the article but then immediately jumps down to the editor toolbar, which is annoying especially when you want to check the beginning of the article. This doesn't happen if syntax highlighting is disabled.

ISTR this being a toggle or config setting somewhere but now I can't find anything about it. This is a pretty vanilla installation without anything fancy in LocalSettings.php, Common.css or any personal .css or .js. What could this be? I haven't tried the master version of CM as I presume it expects MW 1.44+. Tactica (talk) 18:40, 2 May 2025 (UTC) Reply

@Tactica I wouldn't consider enabling $wgCodeMirrorV6 prior to MW 1.44 as stable. Unfortunately Patch Demo doesn't seem to work for MW 1.43, so I don't have a means to easily test this environment.

It is probably fine to use the master branch on 1.43. I don't think there is 1.44-specific functionality, but I could be wrong. It's harmless to try since there are no database changes or the like, so you should be able to rollback to the REL1_43 branch without concern. — MusikAnimal ^talk 19:18, 6 May 2025 (UTC) Reply

@MusikAnimal I tried just in case but the current master available for download makes MW 1.43.1 fail with an internal HTTP 500 error, so I understand it does require 1.44. Anyway that's OK, I can see the "final" CM 6 will be great. Keep up the good work! :-) Tactica (talk) 23:43, 6 May 2025 (UTC) Reply

After using CodeMirror v6 while editing a page, the CodeMirror UI then also appears as the "Input wikitext:" box on Special:ExpandTemplates. I just wanted to check if this was intended to be the case, given that this doesn't seem to happen on wikis that currently use CM v5 (tested on enwiki), and as I couldn't immediately see it listed under Extension:CodeMirror § Differences from CodeMirror 5 :) Best, ‍—‍a smart kitten _[meow] 19:16, 15 July 2025 (UTC) Reply

I have updated the docs, which were becoming increasingly outdated! Help:Extension:CodeMirror also needs some work which I will tend to soon.

The goal is pretty much anywhere you see wikitext or another supported language in an editor, you get syntax highlighting (if you have the preference turned on). — MusikAnimal ^talk 06:58, 17 July 2025 (UTC) Reply

Would it be possible to add a static download url to the latest version? It would really help to automate the update process. Sahfd72 (talk) 10:10, 24 October 2025 (UTC) Reply

Do you mean like Special:ExtensionDistributor/CodeMirror? You can select the "master" branch from the dropdown to get the latest code. There is also a "Download source tarball" link in the infobox of Extension:CodeMirror. — MusikAnimal ^talk 23:08, 25 October 2025 (UTC) Reply

When will features of CodeMirror that only available in old 2010 editor be intergrated into 2017 wikitext editor? Is there any such plans in CodeMirror v7? Nvdtn19 (talk) 05:09, 26 November 2025 (UTC) Reply

The main problem is that VisualEditor uses a CSS hack to hide the wikitext and then overlay the CodeMirror-generated markup on top of it. This makes it impossible for CodeMirror to offer features in VE that change the width or sizing of content, such as code folding. In previous discussions with the Editing team, it did not sound like there was a viable fix for this, unfortunately.

The other problem is that it uses an infinite viewport, which causes severe performance problems on large documents (phab:T184857). I think a fix for this specific problem is at least feasible, at least for someone with expertise in VisualEditor and OOUI architecture.

Your question comes up a lot and I keep asking myself, what defines an editor? Is it just the toolbar? Because that's really all the 2010 editor is if you're using CodeMirror 6. You can turn off the 2010 editor (i.e. 2003 editor) and all of the same CodeMirror features still exist, as well as keyboard shortcuts. So maybe CodeMirror just needs its own toolbar? I.e., the "2025 editor"? — MusikAnimal ^talk 07:37, 26 November 2025 (UTC) Reply

@MusikAnimal: I think you've got a bug in your linting logic. s:en:template:ppoem, has start/end options so that multiple ppoems can be put one after the other and form one content div in the end (by changing the number of opened/closed elements). When in Page:space, it ignores these options, to always behave as if that page's portion was a complete poem (both for display purposes and for correct output html). However, when linting wikitext, it appears that CM does not feed parsoid the namespace, because pages like s:en:Page:Firehead.djvu/223 get lint warnings when editing even though they're correct. — Alien 3
3 3 13:09, 28 December 2025 (UTC) Reply

The REST API endpoint does not seem to support a namespace parameter.析石父 (talk) 02:51, 29 December 2025 (UTC) Reply

Ah, that's a shame. At any rate, could linting be disabled for contentmodel proofreadpage? Since it makes a lot of false positives. — Alien 3
3 3 08:37, 29 December 2025 (UTC) Reply

Hmm, looking at the API they do have a title parameter which I suspect is used to give context including the namespace, but it appears that their slash support is broken so if Page:Firehead.djvu/100 is given (even url-encoded) it interprets it as two parameters, so that's a moot point. — Alien 3
3 3 08:45, 29 December 2025 (UTC) Reply

I have submitted a patch based on your suggestion.析石父 (talk) 13:29, 5 January 2026 (UTC) Reply

In first table link bidiIsolation does not exist on the target page. Please realign or remove.Thanks. --Christian 🇫🇷 FR 🚨 (talk) 17:44, 30 March 2026 (UTC) Reply

Yes Done. Thank you, — MusikAnimal ^talk 23:09, 3 April 2026 (UTC) Reply

When Codemirror 5 went live I locally adjusted the highlighting according to the syntax highlighter I was used to before, which is the one from Schnark, see meta:Community Wishlist Survey 2016/CodeMirror #Color and style customization, with later slight adjustments If I remember correctly. Apparently the one from Rememberthedot uses more or less the same scheme, and both make use of background colors. While most of the style rules still work with CM 6 – I know, that there are some changes as written on the front side of this talk page – one specific behavior is annoying: In CM 5 selected text gets the defined color, a greyish tone, also for the elements with a defined background color, but with CM 6 this is not the case, so if I want to select such an element I have to do this blindly. I’d love getting back the former behavior. I’ve noticed there is a class element .cm-selectionBackground defined. Maybe moving this to the end of the style rules in codemirror.less could help here? — Speravir (talk) – 23:18, 21 April 2026 (UTC) Reply

I have noticed that the selection background isn't visible with some syntax structures like __TOC__ for example, if that's what you mean. We can fix this. I'll file a bug and report back here. — MusikAnimal ^talk 23:47, 21 April 2026 (UTC) Reply

Yes, for __TOC__ it’s the same. But you can also create a rule like .cm-mw-template-ground{background-color:yellow} and then try to select a template. — Speravir (talk) – 01:23, 22 April 2026 (UTC) Reply

Ah, I see! Thank you. I've filed phab:T424122. We'll get a fix in. — MusikAnimal ^talk 02:01, 22 April 2026 (UTC) Reply

It seems to me that the colors in CodeMirror for Lua are quite similar to one another. For example, the color for in (pale pink) and ipairs (pale green) is very similar to each other; in some cases, they are indistinguishable. Also, sometimes they just blend with the black color of variables. I think they need to use more contrasted colors. Repakr (talk) 08:12, 22 April 2026 (UTC) Reply