Replacing the HIGHLIGHT_MAX_LINES and HIGHLIGHT_MAX_BYTES constants with $wgSyntaxHighlightMaxLines and $wgSyntaxHighlightMaxBytes respectively, so sysadmins can adjust the limits to their needs if performance is not of their concern.
Bug: T322293
Bug: T104109
Change-Id: I80768d3cb45ac01c004fc812832878c83ca4ecdb
* Added Parsoid config, and refactored code slightly to
add native Parsoid handlers for parser tags exposed
by this extension.
* Enabled parsoid mode testing on the test file.
* Added html/parsoid sections on a few tests.
* Marked rest of tests as wt2html and wt2wt only since
html2wt and html2html will fail without a html/parsoid section
and there is no real benefit to adding them to all tests.
* Added a couple tests to the known failures list:
- One is because of T299103.
- The other is because Parsoid always emits attributes in the
form <tag .. foo="bar"..> instead of just <tag ... foo ..>
Since Parsoid needs to accept this format that is present on
wikis, I added a html/parsoid section for this test and
added the failures to the known failures list.
Bug: T272939
Change-Id: Ie30aa6b082d4fc43c73296ff2ed6cb8c3873f48f
All of the interactions with `pygmentize` have been refactored into a
new class, conviently called Pygmentize. It is responsible for getting
* pygments version (cached in APCu for 1 hour)
* generated CSS (cached in WAN by version for 1 week)
* lexer list (cached in APCu by version for 1 day)
and actually highlighting stuff! Most code paths differentiate whether
we're using a bundled version of pygments or one that has been
explicitly configured. If using the bundled one, we take shortcuts since
we already know the lexer list, have the CSS generated, etc.
ResourceLoaderPygmentsModule is added to switch between loading
generated CSS from the bundled file or Shellboxing out to get it from
pygments.
Bug: T289227
Change-Id: I2e82e5aa2a71604b87ffb4936204201d06678341
When the `enclose` attribute is used `syntaxhighlight-enclose-category`
is added, and when a <source> tag is used, the
`syntaxhighlight-source-category` is used.
Parser tests verify the tracking category is added when appropriate.
Bug: T241636
Bug: T237267
Change-Id: I7a21c635de426ab024703c04acdc6fa2184daedb
This extension is useless if you can't shell out to pygments.
Depends-On: Iff8512530b08ef509e7ac0b6ed8fe9578ef3e2a1
Change-Id: I3ea7d82ab44516f5e202b6e6b86c1d7ec9a3b642
wfMakeStaticArrayFile() expects an associative array, so let's take this
opportunity to turn the lexer list into one with true as the value. This
allows us to use isset() instead of the slower in_array() when checking
to see if a lexer is known.
Bug: T200626
Change-Id: I7a852ddbcfa7c8ed19ac933205cabd176b20d0cb
We originally started using symfony/process because kzykhys/pygments
depended upon it. But that library was unmaintained and became broken,
so we stopped using it, and just used symfony/process directly.
At the time, the main reason in favor of symfony/process was that it
could pass stdin to pygments, while Shell\Command couldn't - but it can
now (T182463)! On top of that, there are downsides, like not respecting
the default MediaWiki shell limits, being incompatible with core's
firejail support, and requiring an external composer dependency.
Note that because Shell::command() will enforce MediaWiki's normal
limits, it's possible that some large pages may no longer render with
syntax highlighting if they pass those limits.
Bug: T182467
Bug: T181771
Change-Id: Ie1cb72b7eb17d943f79ecae4d94a2110546ef039
This avoids having an extension function, which runs on every request,
regardless of whether it uses syntax highlighting or not.
Change-Id: I890348b73af956819300cce64d0672dcdb209c19
SyntaxHighlight migrated to Pygments nearly 2 years ago, and was
included in the 1.26 release. By now everyone should have cleared their
parser caches, so this hook isn't useful.
Change-Id: Ia267a648ce9188232dd55c6ed3bb2c2fa65223a9
Remove the GeSHi name from filenames and classes where possible. We no
longer actually use GeSHi, and though we cannot rename the extension or
repo atm, we can rename these.
Bug: T164939
Change-Id: I02bc3304d88103c5302f203e788fc73ff20e1050
Our GeSHi class is intended for other extensions making use of GeSHi.
However other libraries or extensions can bring their own GeSHi to the
classloader. In those cases, we cannot find our private modifications
like $compatibleLexers on this class. Instead use
SyntaxHighlightGeSHiCompat for our privact modifications and keep GeSHi
closer to the original implementation.
Bug: T139594
Change-Id: I5c2ba9dfb08ec31f6b5cfd90083cbae0ae0ac3c4
When VisualEditor is not installed, there is no point in registering
resource loader modules that depends on it.
A use case is trying to run tests for the MediaWiki tarball. It comes
with SyntaxHighlight_GeSHi but without VisualEditor.
The patch is based on GuidedTour patch by Matthew Flaschen
https://gerrit.wikimedia.org/r/#/c/305691/ for T143297
A similar one has been done for Cite:
https://gerrit.wikimedia.org/r/#/c/316010/
Change-Id: Idf769e0149f93c099a94b1b7a6cb203273dab881
Provide a translation from Syntaxhighlight compatible Pygments and
GeSHi language names to CodeEditor compatible Ace lexer names
Now when you select php4, the CodeEditor will use the Ace lexer php,
instead of falling back to text mode.
Bug: T148515
Change-Id: Ibc209f97318614f764457726f8d55f4e15276d79
Maintain the inspector for inline snippets (which are editable
but still not creatable).
Bug: T112617
Bug: T57934
Change-Id: I76e36590363d36c0d3db4ec28ce81c4860d9b467
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
The 'direction' rules must not be applied to regular preformatted
text in MediaWiki core, only to syntax-highlighted programming
language code.
(Not reverting the part that removes 'monospace' rule, *that* is
superfluous.)
This reverts commit f834b719b9.
Bug: T103780
Change-Id: Ie7e9123ab3456aa6fff0485431fe81cd5eb31fa2
The styles in MediaWiki core for <pre> already cover this. And
for skins that want different styles, SyntaxHighlight should not
have been overriding it.
Bug: T103780
Change-Id: Ib863288a9a4530b183cf5fdb692489363d82a50f
