User:Remember the dot/Syntax highlighter



I've created a script that makes syntax stand out colorfully in the edit box. Unlike other syntax highlighter scripts such as wikEd, AceWikiEditor, and CodeMirror, this one:
 * Updates the highlighting automatically as you type.
 * Does not break the Undo and Redo buttons.
 * Does not break spellcheck.
 * Is compatible with most other scripts that affect the edit box.

Installation
Please be sure to read the "Known issues" section below before installing the script.

For end user if installed on wiki
If the syntax highlighter is available as a gadget on your wiki, go to your preferences and enable it.

For end user if not installed on wiki
If installation as a gadget is not available, add these lines to your common.js page:

For example, if the English Wikipedia did not provide the syntax highlighter as a gadget, you would add it to https://en.wikipedia.org/wiki/User:Your_Username/common.js

For administrators of Wikimedia sites
On your wiki create the page MediaWiki:Gadget-DotsSyntaxHighlighter.js‎ with the code

Then add to the page MediaWiki:Gadgets-definition‎ a new line *DotsSyntaxHighlighter[ResourceLoader|default]|DotsSyntaxHighlighter.js and create the page MediaWiki:Gadget-DotsSyntaxHighlighter‎ with the text Make syntax stand out colourfully in the edit box.

For administrators of non-Wikimedia sites
On your wiki create the page MediaWiki:Gadget-DotsSyntaxHighlighter.js‎ and copy the source code from User:Remember the dot/Syntax highlighter.js into it. Then add to the page MediaWiki:Gadgets-definition‎ a new line *DotsSyntaxHighlighter[ResourceLoader|default]|DotsSyntaxHighlighter.js and create the page MediaWiki:Gadget-DotsSyntaxHighlighter‎ with the text Make syntax stand out colourfully in the edit box.

MediaWiki 1.22 or later is required.

Compatibility

 * 1) The highlighter works best in the latest version of Firefox.
 * 2) The highlighter works almost all of the time in the latest versions of Chrome, Safari, and Opera, but does not work right with text written in certain scripts, notably Thai and Tibetan.
 * 3) The highlighter does not work in Internet Explorer (its bugs are too severe). The highlighter does not even attempt to execute if Internet Explorer is detected.
 * 4) The highlighter is not compatible with certain scripts that affect the edit box.

Parsing

 * 1) For performance reasons, the highlighter requires all tags to be valid XML. For example, make sure that if you start a   tag you end it with , and use   instead of.
 * 2) For performance reasons, the syntax highlighter can't handle   or  &mdash;it considers them invalid syntax. I suggest using   and   instead.
 * 3) A   tag created by putting a space at the beginning of a line will not be highlighted. This is because the highlighter is not smart enough to tell when a space at the beginning of a line counts as whitespace inside a template.
 * 4)   etc. are not highlighted.

Miscellaneous

 * 1) The highlighter does not perform well when editing long articles and will automatically disable itself if it delays more than 100ms. If this happens, the a message appears explaining what happened and suggesting how to work around it or increase the timeout.
 * 2) The highlighter does not execute when uploading files.
 * 3) The highlighter may override your user styles related to the editing textbox.

Colors
It's easy to change the highlighter to use different colors or to not highlight certain syntaxes. The following color customizations are available:

For example, to make wikilinks cyan and external links orange, put the following in your common.js (if you installed the highlighter as a gadget, omit the first two lines):

To not highlight a syntax, set its color to. For example, to disable external link highlighting:

To not highlight any syntax except those you explicitly want, set  to   and set the color of each syntax you want to highlight. If you just want the usual color, set the color to. For example, to only highlight tags:

Timeout
You can specify a  that replaces the default 100ms timeout. For example, if you're OK with sluggishness as you type and you want to disable highlighting only if it takes more than 150ms, put the following in your common.js:

Again, if you installed the highlighter as a gadget, omit the first two lines.

Reporting bugs

 * Note: Remember to check whether the bug you want to report is already a known issue.

When reporting bugs to me, please include:
 * A detailed description of the problem.
 * A link to a page where the bug is visible, or a sample of wikitext that triggers the problem.
 * Your browser's User-Agent information.
 * The MediaWiki skin you use.
 * A list of gadgets you have enabled.
 * A list of any custom JavaScript or CSS you have enabled.
 * A list of any browser extensions you have enabled.

Source code
To reduce download time and because the ResourceLoader does not automatically minify scripts imported from other wikis, MediaWiki:Gadget-DotsSyntaxHighlighter.js itself is kept in minified form. The actual source code is available at User:Remember the dot/Syntax highlighter.js.

Overview of approach
This script creates a background div, named wpTextbox0, that is inserted behind wpTextbox1, the editing textbox. wpTextbox0 and wpTextbox1 are synchronized in style, and the background of wpTextbox1 is made transparent so that wpTextbox0 shows through. Then, blocks of text are added to wpTextbox0 as span elements. The text on the blocks is transparent, but the backgrounds of the blocks are colored. By using the same text in wpTextbox0 as wpTextbox1, any positioning anomalies from dynamically composed characters are eliminated. Because wpTextbox0 and wpTextbox1 are (theoretically) perfectly synchronized, the colored backgrounds appear to the user as though they have been added directly to wpTextbox1.

The text in wpTextbox0 is not actually added to the textContents of the span elements. Instead, it is added to the :before and :after pseudo-elements of each span using a dynamically generated CSS stylesheet. This avoids problems when trying to use the browser's find-in-page feature, because if textContent were used instead of CSS content, the browser would perceive both the real text in wpTextbox1 and the transparent text in wpTextbox0 to be on the page.