MediaWiki talk:Gadget-DotsSyntaxHighlighter.js

Bug with parser function inside external link
This syntax does not highlight properly in Firefox 32.0.3 on Windows:

[ my text]

The  gets highlighted in yellow, but the external link syntax around it does not. I realize this is a tricky case because the syntax highlighter doesn't call the fullurl parser function, but maybe fullurl is common enough that it should be handled specially. --Maiden taiwan (talk) 15:33, 10 October 2014 (UTC)


 * I think the fullurl syntax is different in different languages, which would make handling it difficult (this is the same reason why etc. are not highlighted). Maybe it's time to engineer in a language pack system to grab the localized text you need for your language and no others. To be honest though, I'm not sure that what you're doing is all that common, and maybe it could be better handled by writing a template that makes a fullurl link automatically. —Remember the dot (talk) 16:59, 10 October 2014 (UTC)


 * Thanks for your quick reply! The fullurl pattern is the recommended solution when you're creating local links with query string arguments, like . On our wiki, this is reasonably common. Anyway, I hope my suggestions are helpful. Maiden taiwan (talk) 18:29, 10 October 2014 (UTC)

r.style.clear = "both";
Just wanted to report that in order to make the highlights match the text on Persian Wikipedia I had to add  to the code (which I think was required because of the special style of some of our toolbars). Thanks for this great gadget. Dalba 27 Aban 1393/ 11:11, 18 November 2014 (UTC)


 * I just tried the mainline code on the Persian Wikipedia and I didn't see any problems. What browser and skin are you using? Have you enabled any special toolbars? (And by the way, the actual source code is at User:Remember the dot/Syntax highlighter.js.) —Remember the dot (talk) 06:57, 19 November 2014 (UTC)
 * I'm using FF 33.1, vector skin. Yes, I've enable a non-default gadget (toolbar) on my account (Sorry that I didn't mention this before, I thought it is a default gadget). To reproduce the problem I think you need to run the code in this gadget so a toolbar will be added to top of the editbox. Then run your own code. Dalba 28 Aban 1393/ 07:26, 19 November 2014 (UTC)
 * I thought this over and I decided to adopt your solution. The syntax highlighter forces the textbox to width:100% anyway, so I don't see the harm in clearing floating elements too. —Remember the dot (talk) 05:56, 11 December 2014 (UTC)

Detecting changes to the text direction
As an RTL user I frequently need to switch direction of the text (using ctrl+shift+x in Firefox), but the direction of highlights is not changed accordingly. I don't know if it's possible or not, or how much it could affect the performance of the script, however it would be very nice if DotsSyntaxHighlighter could detect this. Thanks. Dalba 20 Azar 1393/ 06:51, 11 December 2014 (UTC)


 * Done. Would you like to contribute a Farsi translation of errorMessage while you're at it? —Remember the dot (talk) 18:58, 11 December 2014 (UTC)
 * Sure, I will be glad to. Here it is:
 * - Dalba 20 Azar 1393/ 22:19, 11 December 2014 (UTC)
 * - Dalba 20 Azar 1393/ 22:19, 11 December 2014 (UTC)

Fix error caused by elements
Can the code  be replaced with. Or line 204 from the better formatted script from if (text.charAt(tagEnd - 2) == "/" ) to if (text.charAt(tagEnd - 2) == "/" || match[0].substring(1) == "br" )

This will allow the script automatically treat  elements as self closing, since they are.

Also, is there any specific reason the code here uses generic variables and no whitespace? --KnightMiner (t/c) 16:45, 15 June 2015 (UTC)


 * I am not going to maintain a massive whitelist of every self-closing element that could possibly exist. Use  instead. —Remember the dot (talk) 20:08, 15 June 2015 (UTC)