We could do this using TextContent::fillParserOutput(), but alas it is
'protected', so we have to duplicate a tiny bit of code from there.
Bug: 68757
Change-Id: I7d98fa0f97fb195d23caa3d7448a15c3bbe430ca
Follow-up to I7bbdcc0a, see it for details.
Also cleared up the comment describing this here.
Bug: 26204
Change-Id: I103a6d5c3e1f91cf74e244756c2ad318e429a78e
We want to be able to track what styles were added to be able to deliver
this information to MediaWiki's live preview functionality (in order
to solve bug 24134).
This required moving some code in SyntaxHighlight_GeSHi class around.
The old way still works and is used for MediaWiki 1.20 and lower.
Bug: 24134
Change-Id: Iafd91de8922be55688fedef4e43a8e7f54d4e1cc
A performance issue was fixed in the shim(s) generated by
generateJsonI18n.php, so it needed to be updated.
Change-Id: I68764e4b5e5a2bff2a433edadf343707f544172f
HTML Tidy doesn't care for tabs, and likes to always output spaces. This
can break the syntax-highlighted output, since Tidy converts tabs to
spaces on the source-code level instead of on the rendered HTML level,
even inside <pre> tags where it really shouldn't (this is probably a bug
in Tidy).
r97300 fixed the bad indenting by converting tabs to spaces before
highlighting, which works around Tidy's bug but breaks highlighting of
languages where tabs are significant (e.g. Whitespace).
It turns out that Tidy's tab mangling occurs while it's reading the
source file, before the conversion of entities such as 	 to tab. So
GeSHi can armor its <pre>-wrapped output against Tidy's bug by encoding
all tabs as 	.
Bug: 30930
Bug: 57826
Change-Id: Id541e2712bd3f94446442ccf2e1e2f214e2801ba
Single quotes in Haskell may be used to delimit character literals, but they
can also be used in identifiers. GeSHi's syntax highlighter only recognizes the
former usage. When Haskell source uses "'" as part of an identifier, GeSHi
treats it as the start of a literal string, which screws up syntax
highlighting.
Upstream bug report and proposed patch have been ignored for more than a year,
so I am applying the proposed fix here, and changing the version identifier to
reflect a WMF modification.
Upstream bug report: <http://sourceforge.net/p/geshi/bugs/217/>
Upstream proposed patch: <http://sourceforge.net/p/geshi/bugs/219/>
Bug: 52509
Change-Id: I210832c4b272b5c03bbc4623d73fb821092e5ef4
The regular expression used for number highlighting in GeSHi is highly
recursive, and easily overflows the low PCRE recursion limit on WMF
sites (and, on sites where the recursion limit isn't low, it can easily
crash PHP).
Fortunately, it's easy to fix for the common case.
This is also reported upstream at
https://sourceforge.net/p/geshi/bugs/223/
Bug: 45669
Bug: 36839
Change-Id: I27203c767d1d3f2f0999b1b1d8a06e8cf68c19ed
Currently, the SyntaxHighlight GeSHi extension includes geshi/geshi.php.
This creates a conflict when an up to date GeSHI library exists in PHP included path.
This change let the SyntaxHighlight GeSHi include our bundled version instead.
Change-Id: Ie8f9aa6182a38508201d639723e876c156d8b0d1
Using ContentGetParserOutput instead of ShowRawCssJs allows highliting to be applied
for other kinds of scripts as well (e.g. Lua). It also allows more special case code
for CSS and JS to be phased out.
NOTE: this requires Ibfb2cbef to be merged in core!
Change-Id: Ie260c22680ec9a31e505c685d70e17efe8a7bf44
