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
Try #2. Our last attempt loaded $wgGeSHiSupportedLanguages late, and
would override anything if it was already set. We still load it late, but
only if it is not already set.
This reverts commit 033ca20746.
Bug: T88063
Change-Id: Iae0806e06a95b2d8932b3d9e078e6135dd6750a3
