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
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
It previously supported more values, but since the switch to Pygments
these additional values are no longer supported. It now always
outputs <pre> or <code>, not e.g. <div>.
Change-Id: I406eee0eeeb3b9aaec3fa464ffdf6e200c868b84
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
Follows-up b403b58. When using the content to version the module,
no summaries or modified hashes are used. The content itself is
hashed to naturally invalidate stale cache.
Change-Id: Ic6a20274e19fcf48cb8fe2ef39e48feb7c456391
This way, a visit by a logged-in user to a page with stale syntax highlighting
will also trigger a purge of the page for anons in Varnish.
Change-Id: I366563839c89d9546447d3e58bb9239a36bf70bd
I'm not entirely sure that this will always behave correctly on RTL
wikis, but currently we never behave correctly on RTL wikis.
Bug: T85794
Change-Id: I8af2b18884ec619d581f9ceed737c5628b647086
* Don't json_encode() the whole code block, that's stupidly expensive when the
code is a string already. It's only the options array that needs to be
explicitly stringified.
* Incorporate a cache version parameter input in the cache key so we can manage
changes to the extension's HTML output.
* Only use wfGlobalCacheKey if available, to maintain 1.25 compat.
Change-Id: I8d536f9011763f47667502225ed4459be7d2ed4a
Remove trailing \n after closing </div>, as it results in multiple
newlines that confuse the MediaWiki parser into generating <p><br></p>
all over the place.
Bug: T85794
Change-Id: Iffaa73b49c29e94d8a1a659dd40b845a9f4ce0c1
It was always "none" and not "span", this must've been an accidental change.
Also add a CSS tweak to better render the common pattern of
<code><syntaxhighlight enclose="none">...</syntaxhighlight></code>.
Bug: T85794
Change-Id: I3ed1b7f3c954374b49fc9a97881ea5236415cb6f
* Restore parseHighlightLines() function from before
6484894497, which introduced a
regression in parsing line ranges. There are no tests for this and
I'm not going to debug the regexes.
* Use a space rather than a comma as separator when passing the list
of line numbers to Pygments.
Bug: T85794
Change-Id: Ib86c216308a973000a4129c2c46286ec1dc988e1
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
If Pygments ever adds a dedicated lexer for 'cadlisp', for example, we'd want the
extension to use that, rather than use the compatibility map.
Change-Id: Icc610695ac2826bb526f7c69e867576c660ba6ef
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
'Fancy' line numbers are a fairly useless feature, not seen
in any other code highlighter. As the extension doesn't let you
choose a line number mode, default to normal.
Bug: T101602
Change-Id: Iccbd3ba6c91c58b0ea0f0c09832f1422936cd475
Geshi::error() is a method that returns an HTML string representing
the error.
Geshi->$error is an integer error code.
This code clearly means to compare against the integer code given that
GESHI_ERROR_NO_SUCH_LANG is an integer.
Verified by using eval.php to instantiate "new Geshi( '', 'js' );"
and $geshi->error:
> 2
but $geshi->error():
> "<br /><strong>GeSHi Error:</strong> GeSHi could not find the language"
Change-Id: I1ca77733d4b6b5481c5db6aba9f6b7dda6803099
Follows-up f37cee996e which replaced the getHashMtime() and
getDefinitionMtime() methods with dummies that always return 1.
These getModifiedTime() implementation was only tracking the
definition, which is already tracked by getVersionHash().
Bug: T94074
Change-Id: I6e37c3c2f85ef4599a8643b0efabc18de2f51ec4
