Due to https://github.com/facebook/hhvm/issues/6921, $process->getOutput()
from Symfony/Process doesn't work reliably under HHVM.
This causes the result of "pygmentize" to be unexpectably truncated.
Until this is fixed in HHVM or Symfony, we can use callback of $process->run()
instead of the buggy $process->getOutput().
Bug: T151523
Change-Id: I21ef340eccca0741d7e86840f444272623675c46
kzykhys/pygments provides very little added value when compared to just using
symfony/process directly. Since kzykhys/pygments appears to be unmaintained and
is currently broken, depend on symfony/process directly instead.
Change-Id: I34c7e4201c2c21d3f8607ec826a4c9869e2da917
Task: T120068
So other extensions (e.g. EventLogging) can use it as a public API
instead of having to use the backwards-compat prepare() function.
Change-Id: Iae0cfb838018fc6111feb03c22fb910314387e38
Parser::MARKER_PREFIX is a new constant introduced in MW 1.26,
previously the value was dynamic and available as
$parser->mUniqPrefix. That continues to be supported in MW 1.26+.
Follow-up to 043969f84e.
Bug: T105796
Change-Id: I9dfc9e1a424e28fc4f870dd513306e5144d1ec7c
Follows-up 043969f84e.
This caused a fatal MWException when saving/reading pages that contain a
<source> that couldn't be highlighted (e.g. no lang attribute, unknown
lang, or too large).
Specifically when wgWellFormedXml=false, in which case $out isn't
just from Pygments, but actually from our own Html::element.
Change-Id: Ib299a274d28021b2c7bba52d763dd1e17c1f09ec
* Use 'nowiki' strip marker to prevent list processing (also known as
doBlockLevels()). This resolves various issues related to using
<syntaxhighlight/> blocks in lists and lists suddenly appearing
inside <syntaxhighlight/> blocks. Fixes T17333, T25674, T104067.
* To prevent <p/>-wrapping resulting from the above, add our own
wrapper <div/> around the output.
* Since we already have our own wrapper, remove Pygments' one and
extend it with custom attributes. This resolves some regressions
from the GeSHi migration. Fixes most of T103964.
Bug: T17333
Bug: T25674
Bug: T103964
Bug: T104067
Change-Id: I3afd1224a18549c62cd4a95fd046affa6d1d3b3f
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
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
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
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
* 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
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
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
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 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
Store the list of supported languages in SyntaxHighlight_GeSHi.langs.php, which
is auto-generated via a maintenance script, updateLanguageList.php.
Change-Id: Ie0be7c42fa6716555c3e03e3f28734d7e0302664
Core change I04b1a3842 adds a hook to allow extensions to
syntax-highlight the pretty-printed output from the API.
Change-Id: If0413a1d922ff8a47afc355e0a2cc276cf54b400
We could do this using TextContent::fillParserOutput(), but alas it is
'protected', so we have to duplicate a tiny bit of code from there.
Bug: 68757
Change-Id: I7d98fa0f97fb195d23caa3d7448a15c3bbe430ca
