2007-04-03 22:34:07 +00:00
|
|
|
This extension allows source code to be syntax highlighted on the wiki pages.
|
2007-05-18 21:07:35 +00:00
|
|
|
This README file might be out of date, have a look at the extension page
|
2020-10-06 17:10:18 +00:00
|
|
|
for updated information:
|
2007-05-18 21:07:35 +00:00
|
|
|
|
Highlight using Pygments rather than Geshi
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
2015-06-16 03:52:58 +00:00
|
|
|
https://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi
|
2007-04-03 22:34:07 +00:00
|
|
|
|
2009-12-30 12:02:04 +00:00
|
|
|
== Requirements ==
|
|
|
|
|
|
2021-02-14 21:16:28 +00:00
|
|
|
This version of the extension has been tested with Pygments 2.8.0 and
|
|
|
|
|
MediaWiki 1.35. To get releases of this extension compatible
|
Highlight using Pygments rather than Geshi
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
2015-06-16 03:52:58 +00:00
|
|
|
with earlier versions of MediaWiki, visit:
|
2009-12-30 12:02:04 +00:00
|
|
|
|
Highlight using Pygments rather than Geshi
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
2015-06-16 03:52:58 +00:00
|
|
|
https://www.mediawiki.org/wiki/Special:ExtensionDistributor/SyntaxHighlight_GeSHi
|
2009-12-30 12:02:04 +00:00
|
|
|
|
2007-04-03 22:34:07 +00:00
|
|
|
== Installation ==
|
|
|
|
|
|
Drop symfony/process dependency, use Shell\Command instead
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
2017-12-08 20:57:08 +00:00
|
|
|
Add this line to your LocalSettings.php:
|
Highlight using Pygments rather than Geshi
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
2015-06-16 03:52:58 +00:00
|
|
|
|
|
|
|
|
wfLoadExtension( 'SyntaxHighlight_GeSHi' );
|
|
|
|
|
|
2021-02-14 21:16:28 +00:00
|
|
|
By default, this extension will use a bundled copy of Pygments 2.8.0. If you
|
2015-06-20 01:04:36 +00:00
|
|
|
would like to use a different copy of the library, you can set
|
|
|
|
|
$wgPygmentizePath to point to the path to the 'pygmentize' binary.
|
2007-04-03 22:34:07 +00:00
|
|
|
|
|
|
|
|
== Usage ==
|
|
|
|
|
|
|
|
|
|
On the wiki page, you can now use "source" elements:
|
|
|
|
|
|
|
|
|
|
<source lang="php">
|
|
|
|
|
<?php
|
|
|
|
|
v = "string"; // sample initialization
|
|
|
|
|
?>
|
|
|
|
|
html text
|
2011-02-19 20:34:08 +00:00
|
|
|
<?php
|
2007-04-03 22:34:07 +00:00
|
|
|
echo v; // end of php code
|
|
|
|
|
?>
|
|
|
|
|
</source>
|
|
|
|
|
|
|
|
|
|
== Parameters ==
|
|
|
|
|
|
Highlight using Pygments rather than Geshi
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
2015-06-16 03:52:58 +00:00
|
|
|
For details information of these parameters, see the documentation of Pygments'
|
|
|
|
|
HtmlFormatter at <http://pygments.org/docs/formatters/#HtmlFormatter>.
|
2007-04-03 22:34:07 +00:00
|
|
|
|
Highlight using Pygments rather than Geshi
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
2015-06-16 03:52:58 +00:00
|
|
|
* lang; Defines the language.
|
|
|
|
|
* line; Corresponds to linenos="inline" option.
|
2020-06-22 20:20:56 +00:00
|
|
|
* start; Corresponds to linenostart option.
|
2015-06-25 03:34:13 +00:00
|
|
|
* enclose; If set to "none", corresponds to the nowrap=1 option.
|
|
|
|
|
* inline; Corresponds to the nowrap=1 option.
|
Highlight using Pygments rather than Geshi
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
2015-06-16 03:52:58 +00:00
|
|
|
* highlight; Corresponds to hl_lines option (comma separated).
|
2013-02-20 10:22:46 +00:00
|
|
|
|
|
|
|
|
== Note ==
|
|
|
|
|
|
Highlight using Pygments rather than Geshi
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
2015-06-16 03:52:58 +00:00
|
|
|
Pygments is generous about creating HTML elements: highlighting large blocks of
|
|
|
|
|
code can easily generate enough of them to crash a browser. As a guard, syntax
|
|
|
|
|
highlighting is turned off for code fragments larger than 100 kB.
|