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
Pyglet is an internal web service that listens on port 31337 by default and
which accepts syntax highlighting request via POST. If $wgPygletURL is set to a
URL of a Pyglet instance, the extension will attempt to query the web service
instead of shelling out.
Change-Id: Ic49f4cd77585dbffc5392e80904754ff889b8a63
Until and unless there is an explicit need (and intent to support)
a public interface to use this data elsewhere, there is no need
for it to be a separate module.
It can be its own class, but at the resource level this data should
be considered a JavaScript file. And we don't create separate modules
for each file. They are in the same module unless they should be
semantically loaded in unrelated page contexts.
The module registery is not a javascript class autoloader. There
is a global cost to adding more modules to this registry.
Change-Id: Ifeddef8cfe00b6c115734f92eceab251a0b75bdb
Now that we switched to pygments, there should be mo reason not to
enable this on mobile
Bug: T100563
Change-Id: I008b71d4cef04fb7dc7c2ad574032f9c4645b063
Include Pygments 2.0.2 as an executable zip bundle. Also include a script to
automate the process of creating such bundles and to make it reproducible and
verifiable.
Change-Id: I67e6f804e493f065311164c610dc541a5779654e
GeSHi is unmaintained, lacks support for many popular modern languages, and
suffers from deep architectural flaws, chief among them the inconsistent
tokenization of different languages, each of which requires a custom
stylesheet.
Pygments is a well-maintained alternative. It is, by my count, the most popular
syntax highlighting library around. It is BSD-licensed, actively maintained,
and is widely used in PHP projects.
To keep this easy to review, this change does not include update for l10n
files, and it does not delete the geshi/ directory. I will do those in a
separate patch.
The chief change between this and the previous implementation is that errors
result in the code block not being highlighted, as opposed to not being printed
at all, having been replaced by an angry red error message. I think that is the
right user experience. If you go to StackOverflow or GitHub and try to mark up
your code block as being written in some language that their highlighter
doesn't know about, you don't get an error message -- the code simply doesn't
get highlighted.
Because we don't recursively load dependencies for extensions, to test this,
you will need to create a composer.local.json in $IP and add:
{
"extra": {
"merge-plugin": {
"include": [
"extensions/SyntaxHighlight_GeSHi/composer.json"
]
}
}
}
Then run `composer update`.
Bug: T85794
Change-Id: I07446ec9893fae3d1e394f435d3d95cf8be6bc33
Style modules currently added through addModuleStyles default
to being in the head ("top" position). This is an unhealthy default,
since only critical styles that are needed at pageload should be
in the head. In order to be able to switch the default to "bottom",
existing module positions have to be defined explicitly.
Bug: T97410
Change-Id: Ie120a781ac1950abd7963d6f722aa316b5542b51
