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
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
This should've been the case already and will result in an exception
otherwise in MediaWiki core as of Ibb292d2416839.
Change-Id: I062a224662823224f3104d9e8d05abce47b1da81
There are 100s of instances of this module. This can slow things
down quite a bit in Vagrant when it recomputes the same timestamp
many times.
Change-Id: Iaebafe1acf7a0e30ebf86179961ad52f56bb689f
Follows-up b6d8b1a5b.
Should be more accurate since this bumps whenever we update our
version of Geshi. For other changes in SyntaxHighlight_GeSHi.class
cache should not be pro-actively invalidated.
Change-Id: I1c2040ca9b8719adcbbacd195c5050acb6d93295
Out geshi language list had not been updated after the last update and
we were missing a few language names containing - and _ like php-brief
Bug: T94292
Change-Id: I83bf1aeb95e1ed7c2cd2eba865987a772e3f08eb
The API has wrapped its pretty-printed output since Id9cdf102. Apply an
appropriate class to preserve this now that GeSHi is handling it.
Unfortunately GeSHi itself doesn't support adding more than one arbitrary class
to the <pre> (and we're already using that), so we have to add it in a
post-processing step.
Bug: T88742
Change-Id: I38e41db5c341fe06ff825c82d5a9cd4810b7cc24
The empty() function considers "0" to be empty. Makes empty() useless
for strings.
(cherry picked from commit 8d8fb22ebb)
Bug: T41643
Change-Id: If0e647e3be269edcb23748d246bc564483aff0d2
The version was set from the ExtensionTypes hook (which runs only on
Special:Version). WikiApiary and other API consumers were unable to
detect the version.
This is an amended resubmission of the reverted d69ae1f3ac, in which
the constant was declared twice.
Change include_once to require_once for langs file (follows-up 168e1296).
Bug: T75666
Change-Id: I836e0df942a066d80255c1b68472e7ee58124357
The regular expression used for number highlighting in GeSHi is highly
recursive, and easily overflows the low PCRE recursion limit on WMF
sites (and, on sites where the recursion limit isn't low, it can easily
crash PHP).
Fortunately, it's easy to fix for the common case.
This was reported upstream last time it occurred at
https://sourceforge.net/p/geshi/bugs/223/
Bug: T76352
Change-Id: I9e1f002838ffa546c12baf88517069c78a5e7b9d
(cherry picked from commit f21f048443)
Store the list of supported languages in SyntaxHighlight_GeSHi.langs.php, which
is auto-generated via a maintenance script, updateLanguageList.php.
Change-Id: Ie0be7c42fa6716555c3e03e3f28734d7e0302664
- Match comments non-greedily instead of greedily
- Re-add support for block strings (similar to heredoc)
Bug: 73281
Change-Id: Ib7f6eeb2df17434740fb85cee955d76762b56fe5
Currently extensions that want to add their model to $wgSyntaxHighlightModels
must do so in an extension function since they don't want to assume
that their extension is loaded after SyntaxHighlight GeSHi is.
But by not overwriting the array during initialization, extensions
don't have to worry about load order.
Also require a minimum of MW 1.24 which removed support for
register_globals.
Change-Id: I15c56690d156e90991aa86a3d79dbeaeb18dd6fd
