User talk:Remember the dot/Syntax highlighter

Latest comment: 2 months ago by SMcCandlish in topic Line breaks

How to only highlight references[edit]

What exactly do I put where to end up only highlighting references? --Timeshifter (talk) 06:29, 8 December 2012 (UTC)Reply

Known issue about default page zoom[edit]

Is the "only works on default page zoom" issue something that's being worked on? — OwenBlacker | Discussion 15:36, 30 December 2012 (UTC)Reply

What should i expect to fail with zoom?[edit]

So far, it seems it is working just fine with zoom, even if i change the zoom after loading the edit page. What is known to go wrong when the page is not at the default zoom? --TiagoTiago (talk) 16:20, 23 May 2013 (UTC)Reply

When I change the page zoom on my computer (Firefox 21.0 on Lubuntu 13.04) while editing a page, the highlighting gets at least a little and sometimes a lot out of alignment with the text. If I zoom in before opening the edit page, it seems to work okay. Pretty much the same thing happens on Chrome. I think this is due to bugs in Firefox and Chrome, but I doubt they're going to get fixed anytime soon. If combining the syntax highlighter with page zoom works for you, more power to you, but I wanted to make clear that this combination is unsupported. —Remember the dot (talk) 05:29, 26 May 2013 (UTC)Reply

Text colour instead of background colour[edit]

Hi. I was wondering if it's possible to use your script to change the font colour rather then the background colour. The naive solution of changing background-color to color didn't work leading me to believe that this is due to how the textboxes are created. /Lokal Profil (talk) 14:23, 6 June 2013 (UTC)Reply

I tried several methods to make the letters colorful and determined that there is no decent way to do it; HTML, CSS, and JavaScript were simply not intended to have every feature you would have when developing a desktop application. To make the letters colorful instead of their backgrounds you would have to make the letters transparent, which would also make the caret transparent, which I found unacceptable. WebKit has a proprietary CSS property, -webkit-text-fill-color, that can change text color without changing the caret color, but I do not want to code to any particular browser. So, we're stuck with changing the background color instead. —Remember the dot (talk) 04:37, 21 June 2013 (UTC)Reply
Ah. No worries, at least this means I wasn't missing some obvious solution. Thanks for trying. /Lokal Profil (talk) 16:21, 23 June 2013 (UTC)Reply


I noticed this is not compatible with the regex tool from meta:User:Pathoschild/Scripts/TemplateScript#Regex editor. The highlighting is moved to a position below he wiki code (and the wiki code overlaps with the regex tool). Helder 12:45, 27 June 2013 (UTC)

Improve speed?[edit]

I am using a slightly outdated desktop PC (Intel Pentium 4 CPU 3GHz, 1GB ram, on-board display card) to edit Wikipedia in Firefox. When the syntax highlighter is enabled, the scrolling of the article source window by mouse middle wheel is significantly slowed down. Is there anyway to further improve the speed of the gadget? Thx. -- Sameboat (talk) 03:30, 24 July 2013 (UTC)Reply

If I could, I would... —Remember the dot (talk) 00:20, 29 October 2013 (UTC)Reply

It's too slow on edit big page in Firefox (my PC is 7.8 performance index in Windows 7). Entered symbols appears after 0.5 seconds after buttons press.--JayDi (talk) 20:22, 16 March 2015 (UTC)Reply


This brilliant feature should be default on Wikipedia. I did already ask for it long ago.--Wickey-nl (talk) 14:35, 18 September 2013 (UTC)Reply

wgPageContentModel is not defined[edit]

At some point it stopped working on my wiki (MW 1.21.2 with Vector). In Firefox console I get the message "Exception thrown by ext.gadget.DotsSyntaxHighlighter: wgPageContentModel is not defined". Is there a way to fix this please? Rob Kam (talk) 23:18, 27 September 2013 (UTC)Reply

Fixed as described at For webmaster if using MediaWiki 1.21 or earlier. Rob Kam (talk) 20:12, 16 October 2013 (UTC)Reply

Hotlinking to an always-up-to-date version[edit]

Is it possible to hotlink to the Syntax highlighter? In a similar way to how a hotlinked HotCat can be implemented. The advantage would be the other wiki would then always have the most recent version. Rob Kam (talk) 00:16, 20 October 2013 (UTC)Reply

I've added instructions on how to do this. I never intended for Wikimedia wikis to copy and paste the code, do you know of any which have done so? —Remember the dot (talk) 00:20, 29 October 2013 (UTC)Reply
I've been copy/pasting to my personal wiki. As per the instructions at User:Remember_the_dot/Syntax_highlighter#MediaWiki_1.22_or_later. Rob Kam (talk) 14:27, 29 October 2013 (UTC)Reply

HTML br-tag[edit]

in User:Remember_the_dot/Syntax_highlighter#Parsing the text says: "... and use <br/> instead of <br>." According to this seems not correct:

The <br> tag inserts a single line break.
The <br> tag is an empty tag which means that it has no end tag.
In HTML, the <br> tag has no end tag.
In XHTML, the <br> tag must be properly closed, like this: <br />.

Shouldn't the doc reflect this by saying "... but, as an exception, do not use <br/> instead of <br>."? - DVdm (talk) 22:13, 26 April 2014 (UTC)Reply

That section starts with "For performance reasons, the highlighter requires all tags to be valid XML." <br> is valid HTML but invalid XML and <br/> is both valid HTML and valid XML. —Remember the dot (talk) 20:46, 29 April 2014 (UTC)Reply
Yes, I know. My remark was about the missing space. Normally in XML <whatever /> (note that space between "whatever" and "/") should be used as a shorthand for an empty element <whatever></whatever>. But meanwhile I found that the space is not needed, so <whatever/> (without a space between "whatever" and "/") is also accepted in XML, and thus in XHTML. - DVdm (talk) 14:47, 30 April 2014 (UTC)Reply

installation problem[edit]

Hello, I got this script only to work as I changed the link ctype=application/javascript& to ctype=text/javascript& I got also an error message. I read also this[1] and I don't understand it. :P -- Perhelion (talk) 16:34, 25 May 2014 (UTC)Reply

What browser, OS, and skin do you use? What was the error message? (When reporting bugs, follow the insructions at User:Remember the dot/Syntax highlighter#Reporting bugs.) —Remember the dot (talk) 20:34, 25 May 2014 (UTC)Reply
Ok yes, it seems may rarely the case, I using NOSCRIPT on Win 7 with Firefox (Chrome too) but the thing is I've in the whitelist. Here is the msg:
[NoScript] Blocking nosniff Javascript served from with wrong type info text/x-wiki and included by …
And her is the msb from Chrome (35) without any addon/extension:

Refused to execute script from '…hter.js&action=raw&ctype=application/javascript&smaxage=21600&maxage=86400' because its MIME type ('text/x-wiki') is not executable, and strict MIME type checking is enabled.

Hope that helps. :P I see in the En.WP. the Gadget is linked with ctype=text/javascript&. Best regards -- Perhelion (talk) 18:27, 27 May 2014 (UTC)Reply
Augh, MediaWiki should support ctype=application/javascript, but it doesn't! Thank you very much for bringing this to my attention. I have updated the instructions to use ctype=text/javascript until that is fixed. —Remember the dot (talk) 00:12, 28 May 2014 (UTC)Reply


I've seen an fork of this, with extra options, like bracket highlight on the current corresponding marked bracket (like in most text editors), here. I also ask for an customizing option, the delay timer of 100ms seems IMO a bit low. Best regards -- Perhelion (talk) 16:48, 25 May 2014 (UTC)Reply

Cool, I didn't know Schnark was still working on his fork. My version is designed to have less features but work much faster. As for the timeout, User:Remember the dot/Syntax highlighter#Customizing already says:

Furthermore, you can specify a timeout that replaces the default 100ms timeout. For example:

//syntax highlighter

syntaxHighlighterConfig = {
    timeout: 150, //disable highlighting if it takes more than 150ms
Remember the dot (talk) 20:34, 25 May 2014 (UTC)Reply
Omg I'm so blind! :P thank you! Yes but he is still "inactive" or very busy. -- Perhelion (talk) 18:12, 27 May 2014 (UTC)Reply

Compatibility scroll[edit]

Hello, I've another script which change the scrollTop value (of talk pages) to the bottom, but your script seems change (after a short timer, a jump is clearly visible) this back. I found no solution for this, can you help me? (I changed the wpTextbox1.scrollTop value, but it seems you script take the old value after a timer, maybe use wpScrolltop for this?) (PS. if you can need it, I've made a short German translation of the descripton [2]) PPS: This issue appears not with the Schnark fork. -- Perhelion (talk) 10:41, 1 July 2014 (UTC)Reply

Thanks for bringing this to my attention. It should be fixed now. As far as translations, I would be happy to accept a German translation of var errorMessage. After that, you could translate the user manual into German. —Remember the dot (talk) 17:13, 1 July 2014 (UTC)Reply
Thanks too, it works now! Here is the error string:
Die Syntaxhervorhebung wurde auf dieser Seite deaktiviert, da diese zu lange gedauert hat. Die maximal erlaubte Zeit zur Hervorhebung beträgt $1ms und dein Computer benötigte $2ms. Versuche einige Tabs und Programme zu schließen und klicke \"Vorschau zeigen\" oder \"Änderungen zeigen\". Wenn das nicht funktioniert, probiere einen anderen Webbrowser und wenn immer noch nicht, probiere einen schnelleren Computer.
My pleasure. -- Perhelion (talk) 20:20, 1 July 2014 (UTC)Reply
Committed. —Remember the dot (talk) 06:13, 2 July 2014 (UTC)Reply
Good! Unfortunately I've another small compatibility issue. I use now scrollToCaretPosition because I set the caret to the end (with textSelection standard modul). But the caret (focus) don't appear, but again with the Schnark fork. :-o Greetings -- Perhelion (talk) 13:33, 2 July 2014 (UTC)Reply
Wow* you got it, it works now! Seems it was very easy... ;-) Now I'll do the page translation. Thank you! :-) -- Perhelion (talk) 17:17, 2 July 2014 (UTC)Reply

Hej @Remember the dot: , I've fulfilled the de translation! *uuff* I come back because the caret jumps again on load to the top. (Maybe I can focus after onload-event from the Highlighter!?). Best regards → User: Perhelion 11:18, 2 May 2016 (UTC)Reply

PS: I've tested an old version from you and the focus jumps not back (to the top). But I've made now my fokus to the document.ready and it works now too. Greetings → User: Perhelion 17:05, 2 May 2016 (UTC)Reply


The tab-size CSS property (and its prefixed variants) is not copied to the syntax-highlighting overlay. Can you fix this? — Keφr 10:57, 15 August 2014 (UTC)Reply

Not working[edit]

Hello, Since about 0700 UTC this morning, I've had no colors on my editing screen in English Wikipedia. I've become quite dependent on this script and miss it greatly. Syntax highlighter is still selected on my preferences panel. I am using a PC with a cable modem and FireFox 31.0. It seems to work with Chrome 36.0.1985.143 m, but that's not my preferred browser. It doesn't work on Internet Explorer 11.0.9600.17239 and that's no one's preferred browser. If this is helpful, it seems that the vertical spacing of the lines is greater than usual. Please let me know at w:en:User:SchreiberBike if there's any other information which would be helpful or if you have any pointers. SchreiberBike (talk) 19:05, 21 August 2014 (UTC)Reply

When I go to preferences for MediaWiki and enable Syntax highlighter, it works in MediaWiki, but still not in English Wikipedia. SchreiberBike (talk) 19:09, 21 August 2014 (UTC)Reply
I've posted this to your Wikipedia page as I see that that is your preferred contact. SchreiberBike (talk) 19:35, 21 August 2014 (UTC)Reply
I'll just respond here. Have you tried clearing your browser cache (Ctrl+F5)? Do any suspicious messages appear on your browser console (Ctrl+Shift+J)? No one else (myself included) seems to be having problems. —Remember the dot (talk) 22:37, 21 August 2014 (UTC)Reply
I tried clearing the cache and there were no changes and I couldn't tell what was suspicious in the browser console, but I reopened FireFox in safe mode and found that the highlighter worked. Then I started disabling extensions and found that if Privacy Badger is disabled, it works again. I don't know why that would be, but it seems to be taken care of. Thanks for your help and thanks again for making this syntax highlighter available to us all. SchreiberBike (talk) 00:11, 23 August 2014 (UTC)Reply
OK, good to know. —Remember the dot (talk) 21:07, 23 August 2014 (UTC)Reply
I noticed the same problem with Privacy Badger. To get the highlighter to work, set to allow or block cookies Mduvekot (talk) 04:34, 8 February 2016 (UTC)Reply

Greek translation[edit]

Please update this great gadget with this:

errorMessage["el"] = "Η έμφαση σύνταξης έχει απενεργοποιηθεί σε αυτήν τη σελίδα γιατί αργούσε πολύ. Ο μέγιστος επιτρεπτός χρόνος για την έμφαση σύνταξης είναι $1ms και ο υπολογιστής σας έκανε $2ms. Δοκιμάστε να κλείσετε μερικές καρτέλες και προγράμματα και να κάνετε κλικ στην «Εμφάνιση προεπισκόπησης» ή στην «Εμφάνιση αλλαγών». Αν αυτό δεν δουλέψει, δοκιμάστε έναν διαφορετικό περιηγητή και αν ούτε αυτό δουλέψει, δοκιμάστε έναν ταχύτερο υπολογιστή.";

--Ioannis Protonotarios 20:24, 18 November 2014 (UTC)Reply

Ευχαριστώ!Remember the dot (talk) 07:02, 19 November 2014 (UTC)Reply

Syntax Highlighter in Wikia[edit]


I'd like to let you know that we recently implemented your solution into Wikia stack. Link to code:

You can see it in action on one of wikias:

Thanks for great job of creating it. I hope it will serve well Wikia users. R-Frank (talk) 12:54, 23 March 2015 (UTC)Reply

Cool! I'm glad you like it. You'll probably want to check back here periodically for bug fixes though. Just yesterday I committed this fix because a user pointed out a bug to me. —Remember the dot (talk) 19:51, 24 March 2015 (UTC)Reply


Hi there! I wanted to note that I have been using syntax highlighter, but it's got some errors. Wikipedia now (for a few years) uses HTML5, where both <br /> and <br> are valid (the space and slash are both optional). However, <br> still throws up error code (colors the text), making syntax highlighter much less useful. I am mostly active on the English wikipedia, so that is the best way to get a hold of me. en:User talk:Ogress (User talk:Ogress) 22:45, 4 July 2015 (UTC)Reply

The issue is still present. Please add support for normal <br> tags, as is standard for HTML5. Asking everybody not to use it to make the wikitext compatible with syntax highlighter is just a lot of headache. Jack who built the house (talk) 14:43, 9 June 2016 (UTC)Reply

Shifted color positions[edit]

When I add the gadget, the edit box does something like this:

Shift the code some five lines down
Start coloring from the topleft corner

This in enwiki, current Firefox atop WinXP.

Is this the Known Issue: "The highlighter is not compatible with certain scripts that affect the edit box"? -DePiep (talk) 23:07, 20 December 2015 (UTC)Reply

Change image[edit]

File:Dot's Syntax Highlighter 2012-12-06.png doesn't show much of the syntax, just a bit of the inbox, notably references are not highlighted. I suggest using a different image to illustrate the usefulness and potential of this script. I don't see anything better in commons:Category:Dot's Syntax Highlighter, but I am sure we can upload a screenshot easily. --Piotrus (talk) 04:00, 15 May 2016 (UTC)Reply

HTML5 and MediaWiki[edit]

@Remember the dot: We will have some problems with self-closed tags. meta:Tech/News/2016/20 and phabricator:T134423. I think 'XML compatibility' must be discarded. Iniquity (talk) 20:58, 27 May 2016 (UTC) Iniquity (talk) 21:09, 27 May 2016 (UTC)Reply

The syntax highlighter only tries to highlight absolutely correct syntax; the behavior of incorrect syntax is undefined. It is perfectly fine for the syntax highlighter to do whatever it wants with <div/> and <span/> because this syntax is considered incorrect. So, these non-void self-closed tags will continue to be highlighted, and it will be up to the users to fix the syntax. —Remember the dot (talk) 05:30, 13 June 2016 (UTC)Reply
<br> is right. <br /> isnt right. And because of that we have broken highlighting.:( Iniquity (talk) 21:08, 16 June 2016 (UTC)Reply
HTML5 considers both forms to be perfectly valid. To improve the highlighter's performance (the #1 complaint about it), and to encourage consistency with tags like <references/>, the highlighter requires <br/>. Note that the space in the tag is optional. I've explained this many, many times before, and it has nothing to do with the issue you brought up in May. —Remember the dot (talk) 05:34, 17 June 2016 (UTC)Reply
By the way, if the highlighter did highlight <br> the way that you want, people would still complain about how it doesn't know where a <p> tag ends without an explicit </p>, or that it messes up on italics after an apostrophe like in French words (e.g. L'''home''). The only way that the highlighter can perform reasonably quickly is if it only handles simple, consistent, straightforward syntax, and simple syntax is better for new users anyway because it doesn't require memorizing the HTML5 specification. —Remember the dot (talk) 05:53, 17 June 2016 (UTC)Reply

Conflict with RefToolbar[edit]

The syntax highlighter tool -- which I love and am so thankful for as it makes editing amazing and enjoyable -- appears to be creating a functional problem with the RefToolbar. Dropdown menus are not working if the tool is turned on. See ticket over at Phabricator and Loss of functionality thread. Just wanted to mention this if anyone else is using WikiMarkup and is having problems. -- Erika aka BrillLyle (talk) 10:44, 22 September 2016 (UTC)Reply

I'm having the same problem, and disabling the syntax highlighter solved it for me. But I really like using both... Rachel Helps (BYU) (talk) 19:21, 22 September 2016 (UTC)Reply

Incorrect display on Firefox and Chrome.[edit]

Recently (several weeks) I have been getting unpredictable displays from the syntax highlighter, which I find a very valuable tool when it works. Sometimes it works as expected and highlights the text in the edit window. more often, it highlights a chunk of white space about the same size as the edit window, directly below the preview, with what may well be the correct pattern of highkights, and the text in the edit window is not highlighted at all. This does not seem to be affected by the edit toolbar, which I usually use for creating citations, which is another story. as long as I dont save this seems to be stable, but after a save all bets are off. it may come back either way for the next edit, but probably 80% of the time defective. There is no obvious pattern and I usually have the latest versions of Chrome (on the laptop) and Firefox (on the desktop). This applies to English Wikipedia, where I am active at present I find the same pattern with screen magnification 100% or 120%. Some days seem to be worse than others. Is this a known problem? If so is there a fix? I have it selected as a gadget in preferences. Cheers, Pbsouthwood (talk) 19:53, 22 November 2016 (UTC)Reply

I'm sorry to hear that. Are you sure that you turned the syntax highlighter on in your preferences? On the English Wikipedia, you are importing it in your common.js. If you also have it turned on under Preferences (i.e. if you are importing it twice), I would have expected your browser to freeze entirely. —Remember the dot (talk) 03:57, 28 November 2016 (UTC)Reply
Quite sure. I have now turned it off in my preferences, and it doesn't work at all. I would like it to work over as large a range of projects as is possible - Wikipedia, Wikivoyage and Wikiversity are top of the list. What is the best way to go about this? Do I need to select it in preferences for each project? Does the common.js work over all projects? I have no idea how this works... Cheers, Pbsouthwood (talk) 05:32, 29 November 2016 (UTC)Reply
Oh I see, you were importing the highlighter from instead of This is probably why you were having problems. I've deleted the erroneous code from your common.js on the English Wikipedia. You will have to manually enable the syntax highlighter on each wiki site you use, either by enabling it in your preferences or by importing it in your common.js page. For starters, go to the English Wikipedia, enable the highlighter in your preferences there, and let me know whether or not that works now. —Remember the dot (talk) 06:16, 2 December 2016 (UTC)Reply
Eish! So many ways to get it wrong! Seems to be working now on Firefox, really good to have it back. Thanks. Will report back after testing on chrome on the laptop. Pbsouthwood (talk) 09:30, 2 December 2016 (UTC)Reply
Looks good on Chrome too. Cheers,Pbsouthwood (talk) 18:13, 2 December 2016 (UTC)Reply
Glad to help. I've blanked meta:User:Remember the dot/Syntax highlighter.js so that trying to import the highlighter from there now does nothing instead of causing an error. So, thanks for bringing this problem to my attention. —Remember the dot (talk) 05:01, 3 December 2016 (UTC)Reply
Excellent, Cheers, Pbsouthwood (talk) 17:41, 3 December 2016 (UTC)Reply

Blackskin compatibility[edit]

There is a color issue with the Green on black skin on English Wikipedia. Could you add class to the container div and maybe a base foreground/background color? Dispenser (talk) 14:30, 1 May 2017 (UTC)Reply

Have you tried customizing the highlight colors? —Remember the dot (talk) 04:12, 9 May 2017 (UTC)Reply
Using JavaScript is the wrong way to change presentation. Additionally, the script is broken with the High Contrast theme (white text on black backgrounds) in Firefox/Windows 7. Dispenser (talk) 14:47, 9 May 2017 (UTC)Reply
Rewriting the highlighter to allow CSS styling would result in both poor performance and ugly CSS. However, if you suggest highlight colors that work well against a dark background, I could make them the default for high-contrast users. —Remember the dot (talk) 07:37, 10 May 2017 (UTC)Reply
At minimum provide a base class for the root CSS. That way I can clobber any styling. Dispenser (talk) 01:45, 12 May 2017 (UTC)Reply
It sounds like what you want is to detect whether the syntax highlighter is running, and force the background to be white if it is. If that's the case, then I think the best thing would be to make the highlighter use a white background by default and require a config variable such as backgroundColor to override it. Is that acceptable? —Remember the dot (talk) 03:32, 14 May 2017 (UTC)Reply
Yes, but with a CSS class I can apply filter:invert(100%) hue-rotate(180deg); that'll invert it without changing the color. Also, force the text black. If you want to go the extra mile and include an automatic high contrast; window.getComputedStyle(wpTextbox1).getPropertyValue("background-color") returns rgb(0, 0, 0) with the high contrast theme. Dispenser (talk) 02:52, 15 May 2017 (UTC)Reply
The highlighter now uses black text on a white background unless overridden in a config variable.[3] I also added id="wpTextbox0" to the background div so that you can apply CSS filters if you want. —Remember the dot (talk) 01:51, 18 May 2017 (UTC)Reply
Yay! I've had to add filter:saturate(6) because of the sRGB gamma curve killing the brightness. Dispenser (talk) 23:48, 19 May 2017 (UTC)Reply


It's been raised in this discussion on enwiki that the syntax highlighter may be breaking lines in two and starting the second line with a space. Of the possibilities raised I only have this highlighter enabled, so I'm bringing it to your attention. Thanks. Cabayi (talk) 07:13, 5 October 2017 (UTC)Reply

My syntax highlighter is totally passive; it can't alter the text you input. There must be something else going on. —Remember the dot (talk) 03:51, 7 October 2017 (UTC)Reply

New Wikitext Editor[edit]

Would it be possible to make this work with the new version of the wikitext editor? --TerraCodes (talk) 04:38, 21 November 2017 (UTC)Reply

Theoretically yes, but it's not something that I'm going to worry about right now. It'd be better for the developers of the new editor to build syntax highlighting into the editor without relying on a gadget. —Remember the dot (talk) 06:55, 28 November 2017 (UTC)Reply


Hello, thank you very much for this great tool. It is pretty efficient and fast. In my own experience, timeout occurred only one (or maybe two) time in dozens of thousands pages' openings in edit mode with Firefox.
My suggestion is to offer the possibility to highlight a text pattern (as a regepx or a simple string) which could be defined in the configuration. Something like:

syntaxHighlighterConfig = {
    myPattern: { pattern: "myRegexp", color: "myColor" }

All the best. --ContributorQ (talk) 17:17, 10 December 2017 (UTC)Reply

Hi, I'm glad you like the syntax highlighter! There is not really an easy way to integrate arbitrary regular expressions into the syntax highlighter, I am concerned about how it would affect performance, and I don't see much usefulness in it. So, this is not a feature I plan to work on, but you are always welcome to copy the source code and modify it on your own. —Remember the dot (talk) 03:26, 29 January 2018 (UTC)Reply
Thanks for your answer. I will try to customize your original version. --ContributorQ (talk) 23:32, 6 February 2018 (UTC)Reply

Highlighting above editor window - 1.31[edit]

Hello! Thanks for great gadget. I updated Mediawiki from 1.26 to version 1.31. Now the highlighting shows above the editing window. The source of problem is related to 'usebetatoolbar' option in WikiEditor. If I switch it off, everthing works ok, but users have only few buttons in menu. It seems that menu and highlighting work on the same layer or something like that. Behavior is the same on Vector and Timeless. What's interesting, enabling reCaptcha solves the problem. I have no other gadgets. Dolosw (talk) 19:21, 6 August 2018 (UTC)Reply

The Wikimedia sites are at 1.32, and I don't see any problems here. Are you using the latest version of Syntax highlighter.js on your site? —Remember the dot (talk) 23:02, 5 August 2018 (UTC)Reply
Yes, I updated all the extensions and gadgets. I looked on Wikimedia and I can't find the difference. I switched to code mirror which works ok. But I will test gadged in following days. Dolosw (talk) 19:21, 6 August 2018 (UTC)Reply

ES6 features are now used, no compatibility issues with old MW versions are mentioned in the installation guide[edit]

This revision introduces ES6 features like const and let. As far as I know, these are not compatible with MediaWiki versions less than 1.33. I experienced this problem when copying the highlighter code as a gadget to a non-Wikimedia wiki running MW 1.31 (the section says MW 1.22 or greater is required). The version of the script previous to the one I linked worked. --AttemptToCallNil (report bug; view backtrace) 11:40, 6 August 2019 (UTC)Reply

Thanks for pointing that out. It turns out that the minifier still chokes on ES6 even in MediaWiki 1.33. Consequently I have reverted the syntax highlighter's code to the ES5 version. —Remember the dot (talk) 06:43, 9 August 2019 (UTC)Reply

Line breaks[edit]

The highlighter recognises <br />, but not <br>. AIUI, the latter is preferred. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:39, 26 August 2019 (UTC)Reply

Well, it's what WHATWG likes, but more parsers handle the ‎<br /> form, so we should prefer it, at least for a project like Wikipedia where our content is meant to be maximally reusable. Not every form of concision/compression is an improvement 100% of the time.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:47, 25 January 2024 (UTC)Reply

It does not work in Persian with the site[edit]

It does not work in Persian with the site and it looks bad --Sokote zaman (talk) 17:44, 21 May 2020 (UTC)Reply

I looked at the Farsi Wikipedia today and it looked fine. Could you provide some more information? —Remember the dot (talk) 04:41, 22 May 2020 (UTC)Reply

Context Search with Ctrl-F[edit]

Context Search with Ctrl-F generated misaligned highlight selections. Highlight selection boxes appears in one places , but actual text located in another places. (FF 78, windows) Warmagain (talk) 13:07, 21 July 2020 (UTC)Reply

What page were you editing when you experienced this problem? —Remember the dot (talk) 04:48, 29 July 2020 (UTC)Reply
I'm getting this too on English Wikipedia using Firefox. If a string occurs twice in an article, ctl-f reports that there are four of them and when going to the next instance, it will flash them the first two times before going to the version I can see and edit. If I turn off the highlighter it stops. This only occurs in the edit window. It's been doing it for a while now, maybe a month. It doesn't happen in Chrome. It's annoying but can be dealt with.SchreiberBike (talk) 04:25, 3 August 2020 (UTC)Reply
I wanted to report that I am also experiencing this issue throughout the English Wikipedia. It occurs in Firefox but works fine in Chrome. NTox (talk) 07:43, 9 August 2020 (UTC)Reply
Thank you for the bug report. I believe I have resolved the problem. Please let me know if you continue to see anything strange. —Remember the dot (talk) 05:11, 11 August 2020 (UTC)Reply


Is it possible to use WikEd colors? Doc James (talk) 08:28, 29 December 2021 (UTC)Reply

User:Wbm1058 partially build this a few years back.[4] But does not seem to be working now. Doc James (talk) 04:42, 22 January 2022 (UTC)Reply

Hungarian translation[edit]

For the multi-language message, beginning in line 418, the Hungarian version is:

hu: "A szintaxiskiemelés ezen az oldalon le lett tiltva, mert túl sokáig tartott. A maximális engedélyezett kiemelési idő $1ms, és a géped $2ms-ig dolgozott. Próbálj meg bezárni néhány fület és programot, és klikkelj az „Előnézet megtekintése” vagy a „Változtatások megtekintése” gombra. Ha ez nem működik, próbálj meg egy másik böngészőt, és ha ez sem működik, próbáld meg egy gyorsabb gépen.",

Please add to the code. Thanks. Tilarvehulor (WMM) (talk) 17:51, 6 January 2022 (UTC)Reply

Done, thank you! —Remember the dot (talk) 04:29, 29 March 2022 (UTC)Reply

How to highlight a specific keywords?[edit]

Hi, is there any possible way to do a highlight a specific keywords in a wikitext, let say "Foo" or "bar" as examples? Shinjiman (talk) 09:16, 26 August 2022 (UTC)Reply

No, that's beyond the scope of this gadget. It is, however, open source and you are welcome to fork it and modify it to suit your needs. —Remember the dot (talk) 03:45, 31 August 2022 (UTC)Reply
Thanks, let see if I can modify those scripts to suit for its purposes. :) Shinjiman (talk) 01:55, 13 September 2022 (UTC)Reply

Size of font[edit]

I recently turned this gadget on, which would be very helpful for me as using source editing, however a little bit annoying that the size of the characters is slightly smaller in the edit window than without the gadget. Is there any settings to make the same size as I used to see? Thanx. JSoos (talk) 13:02, 26 October 2022 (UTC)Reply

You can increase the font size of the edit box by adding some CSS to your common.css page, for example:
#wpTextbox1 {
    font-size: 14px;
If I remember correctly, the syntax highlighter needs the font size to be an integer pixel value, which is probably why your original font size is being rounded down. —Remember the dot (talk) 21:27, 12 November 2022 (UTC)Reply
Thanx, it seems it was set to 13.5, but 14 much better for me, than 13. JSoos (talk) 21:44, 12 November 2022 (UTC)Reply

Edit text separated from highlighting[edit]

I encountered a problem when trying to edit any page on English Wikipedia an hour or so ago. I'm using Firefox 117 on Windows 10 but it also occurs on Chrome, and the problem disappears if I log out or disable javascript. It also disappears if I disable the Syntax highlighter gadget, so I think the problem must lie with this gadget or with an interaction it is having with something else. I'm using Vector 2022, and I have restarted Firefox several times. When I open the text edit window, the text is pushed down by many lines, with the highlighting appearing in the new blank space rather than over the text. The text overlaps with the material which is supposed to be below it, including the edit summary bar and the "Publish changes" button. An image is at en:File:Syntax hightlighter error.jpg.-Gadfium (talk) 02:34, 3 September 2023 (UTC)Reply

I turned the syntax highlighter gadget back on, a few hours later, and everything is fine. I've made no other change to my configuration. Strange.-Gadfium (talk) 06:56, 3 September 2023 (UTC)Reply
From your screenshot, it looks like you're trying to use both the built-in MediaWiki syntax highlighter and the syntax highlighter gadget at the same time. Thank you for bringing that to my attention: The two stopped playing well together today as a result of making the syntax highlighter gadget play better with the new Live Preview feature. The problem should be fixed now, but if you are still experiencing problems, just click the marker button in the toolbar to turn off the built-in syntax highlighter. Please let me know if you run into any other problems. —Remember the dot (talk)
Great, thank you. I'll turn off the built-in highlighter if I get future problems.-Gadfium (talk) 08:56, 3 September 2023 (UTC)Reply

Apostrophe italic[edit]

Your docs presently say:

For performance reasons, the syntax highlighter can't handle '''apostrophe italic'' or ''italic apostrophe'''—it considers them invalid syntax. I suggest using '<i>apostrophe italic</i> and <i>italic apostrophe'</i> instead.

The more usual approach, at least at en.wikipedia, is:

'<nowiki />''apostrophe italic'' and ''italic apostrophe'<nowiki />'' instead, as it is pure wikimarkup and requires no mixing of wikimarkup and HTML markup (we don't presume that our users know any HTML at all).

 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:20, 25 November 2023 (UTC); rev'd. 12:12, 27 November 2023 (UTC)Reply

Namespace limitation[edit]

I honestly would prefer not to need to make ‎<br>‎<br /> tweaks on talk pages, to keep the whole page from turning pink after the offending element, because those pages are not part of the encyclopedia [or other project] content. So, the #Ignoring_unclosed_br_and_hr_tags JS tweak is appealing. However, it would be better to be able to find and change such instances to ‎<br /> in actual articles, because it is properly parsed by more parsers. I don't know enough JS tricks to limit the br-ignoring to particular (talk) namespaces, but am wondering if there's a way to actually do this.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:11, 27 November 2023 (UTC)Reply

Update: This should work:

/* From:
    but docs warn "this will impact performance": */
    // SMcCandlish tweak: limit to to when the URL path contains "Talk:" or "_talk:"
    if (/(?:Talk|_talk:)/i.test(window.location.pathname)) {
        syntaxHighlighterConfig = {
            voidTags: ["br", "hr", "BR", "HR"],

However, it's not working. When I remove that code and just go with your original:

    syntaxHighlighterConfig = {
        voidTags: ["br", "hr", "BR", "HR"],

That doesn't work either, even with that at the very top of my common.js (I'm using the gadget-installed version at Any idea what's going on here? Why would this basic functionality break?  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:44, 25 January 2024 (UTC)Reply