The data module was not working properly in debug mode because since
Ifeddef8c we've extended FileModule which just tries to use URLs.
Change-Id: I822c2e64926a3d6bf1ea53e4fa27bc544ede87d1
"dcl" (Data Control Language) in GeSHi was SQL with
additional keyword support, and a fallback to pygments
'sql' renders correctly, albeit without all keywords
highlighted, however most of the keywords are part of 'sql'.
Change-Id: I121ce6d6ab20328dd1788f537127e16fa3049503
Parser::MARKER_PREFIX is a new constant introduced in MW 1.26,
previously the value was dynamic and available as
$parser->mUniqPrefix. That continues to be supported in MW 1.26+.
Follow-up to 043969f84e.
Bug: T105796
Change-Id: I9dfc9e1a424e28fc4f870dd513306e5144d1ec7c
"arm" in GeSHi was assembly with additional keyword support,
and a fallback to pygments 'asm' renders correctly.
Change-Id: I3eb354cda2a1f324dd539eb20e9801c8350e21d1
Follow-up to 043969f84e.
It is not needed for current HTML generated by the extension tag,
but is required for compatibility with cached renders generated
between 6484894497 and
043969f84e.
Bug: T105499
Change-Id: Ie15d9c7fb673528b2ab5e40e6beddc580fb6d368
Follows-up 043969f84e.
This caused a fatal MWException when saving/reading pages that contain a
<source> that couldn't be highlighted (e.g. no lang attribute, unknown
lang, or too large).
Specifically when wgWellFormedXml=false, in which case $out isn't
just from Pygments, but actually from our own Html::element.
Change-Id: Ib299a274d28021b2c7bba52d763dd1e17c1f09ec
* Use 'nowiki' strip marker to prevent list processing (also known as
doBlockLevels()). This resolves various issues related to using
<syntaxhighlight/> blocks in lists and lists suddenly appearing
inside <syntaxhighlight/> blocks. Fixes T17333, T25674, T104067.
* To prevent <p/>-wrapping resulting from the above, add our own
wrapper <div/> around the output.
* Since we already have our own wrapper, remove Pygments' one and
extend it with custom attributes. This resolves some regressions
from the GeSHi migration. Fixes most of T103964.
Bug: T17333
Bug: T25674
Bug: T103964
Bug: T104067
Change-Id: I3afd1224a18549c62cd4a95fd046affa6d1d3b3f
Do this by having SyntaxHighlight_GeSHi::highlight() return a Status object
rather than a plain string, and by making it the highlight method's job to look
up a lexer for a language. The actual warning text is not outputted anywhere
yet; deferring that for a follow-up patch.
Bug: T103586
Change-Id: Id839f925a56ab09a8423958327b9aefd7207ef37
MZMcBride noticed the red border around '國' in
https://en.wikipedia.org/wiki/Swift_(programming_language)#Example_code
That particular case happens to be a Pygments bug, because multibyte characters
are valid variable names in Swift. But even in cases of legitimate syntax
errors, I don't think we want to show the red border. This behavior may be
useful in code editors, but it is not useful in a wiki environment, especially
given the longstanding habit of using an existing, mostly-compatible lexer to
highlight a language for which no specific lexer exists.
To fix this, override the style in pygments.wrapper.css, and swap the order in
which the two CSS files are concatenated, so that in general we have the
ability to override Pygments-generated CSS.
Change-Id: I304fdaf3a462445d316e0f7fecc983fa87afc629
This makes installation easier for local development.
Per https://www.mediawiki.org/wiki/Manual:External_libraries
I was supicious about whether 'use KzykHys\Pygments\Pygments;'
works in a file if the namespace/class itself is only loaded
later, but it works fine.
Ref T103890.
Change-Id: Ia1a577f555cd8ab09969dec219316bc1e76769f4
Before we started using the 'code' tag for inline code snippets,
<code><syntaxhighlight enclose=none ...>...</syntaxhighlight></code>
was a common pattern. Continue supporting it in existing content.
Follow-up to 04293baad9. My IRC comments
about this were seemingly forgotten, and the code I added in
5b7522a5fc to handle this problem
unceremoniously removed.
Bug: T85794
Change-Id: I8e52089fed41e78fb60ddd5b7c12075056265dd9
