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
|
|
|
<?php
|
|
|
|
/**
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
* http://www.gnu.org/copyleft/gpl.html
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Stub object for maintaining backward-compatibility with extensions
|
|
|
|
* that have not been updated for version 2.0 of SyntaxHighlight_GeSHi
|
|
|
|
* and for supporting GeSHi lexer names whenever they map naturally to
|
|
|
|
* a Pygments lexer.
|
|
|
|
*/
|
|
|
|
class GeSHi {
|
|
|
|
/** @var array A mapping of GeSHi lexer names to compatible Pygments lexers. */
|
|
|
|
public static $compatibleLexers = array(
|
2015-07-13 03:12:12 +00:00
|
|
|
// Assembler
|
|
|
|
'arm' => 'asm',
|
|
|
|
'6502acme' => 'asm',
|
|
|
|
'6502tasm' => 'asm',
|
|
|
|
'6502kickass'=> 'asm',
|
|
|
|
'68000devpac'=> 'asm',
|
|
|
|
'dcpu16' => 'asm',
|
|
|
|
'm68k' => 'asm',
|
|
|
|
'mmix' => 'nasm',
|
|
|
|
'mpasm' => 'asm',
|
|
|
|
'pic16' => 'asm',
|
|
|
|
'z80' => 'asm',
|
|
|
|
|
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
|
|
|
// BASIC
|
|
|
|
'xbasic' => 'basic',
|
|
|
|
'thinbasic' => 'basic',
|
|
|
|
'sdlbasic' => 'basic',
|
|
|
|
'purebasic' => 'basic',
|
|
|
|
'mapbasic' => 'basic',
|
|
|
|
'locobasic' => 'basic',
|
|
|
|
'gwbasic' => 'basic',
|
|
|
|
'freebasic' => 'basic',
|
|
|
|
'basic4gl' => 'basic',
|
|
|
|
'zxbasic' => 'basic',
|
|
|
|
'gambas' => 'basic',
|
|
|
|
'oobas' => 'basic',
|
|
|
|
'bascomavr' => 'basic',
|
|
|
|
|
|
|
|
// C / C++
|
|
|
|
'c_loadrunner' => 'c',
|
|
|
|
'c_mac' => 'c',
|
|
|
|
'c_winapi' => 'c',
|
|
|
|
'upc' => 'c',
|
|
|
|
'cpp-qt' => 'cpp',
|
|
|
|
'cpp-winapi' => 'cpp',
|
|
|
|
'urbi' => 'cpp',
|
|
|
|
|
|
|
|
// HTML
|
|
|
|
'html4strict' => 'html',
|
|
|
|
'html5' => 'html',
|
|
|
|
|
|
|
|
// JavaScript
|
|
|
|
'jquery' => 'javascript',
|
|
|
|
'ecmascript' => 'javascript',
|
|
|
|
|
|
|
|
// Microsoft
|
|
|
|
'vb' => 'vbnet',
|
|
|
|
'asp' => 'aspx-vb',
|
|
|
|
'visualfoxpro' => 'foxpro',
|
|
|
|
'dos' => 'bat',
|
|
|
|
'visualprolog' => 'prolog',
|
|
|
|
'reg' => 'registry',
|
|
|
|
|
|
|
|
// Miscellaneous
|
|
|
|
'cadlisp' => 'lisp',
|
|
|
|
'java5' => 'java',
|
|
|
|
'php-brief' => 'php',
|
|
|
|
'povray' => 'pov',
|
|
|
|
'pys60' => 'python',
|
|
|
|
'rails' => 'ruby',
|
|
|
|
'rpmspec' => 'spec',
|
|
|
|
'rsplus' => 'splus',
|
2015-07-18 07:09:08 +00:00
|
|
|
'gettext' => 'pot',
|
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
|
|
|
|
|
|
|
// ML
|
|
|
|
'ocaml-brief' => 'ocaml',
|
|
|
|
'standardml' => 'sml',
|
|
|
|
|
|
|
|
// Modula 2
|
|
|
|
'modula3' => 'modula2',
|
|
|
|
'oberon2' => 'modula2',
|
|
|
|
|
|
|
|
// SQL
|
2015-07-15 22:47:11 +00:00
|
|
|
'dcl' => 'sql',
|
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
|
|
|
'tsql' => 'sql',
|
|
|
|
'plsql' => 'sql',
|
|
|
|
'oracle11' => 'sql',
|
|
|
|
'oracle8' => 'sql',
|
|
|
|
|
|
|
|
// REXX
|
|
|
|
'oorexx' => 'rexx',
|
|
|
|
'netrexx' => 'rexx',
|
2015-06-23 18:29:08 +00:00
|
|
|
|
|
|
|
// xpp is basically Java
|
|
|
|
'xpp' => 'java',
|
2015-07-12 02:56:40 +00:00
|
|
|
|
|
|
|
// bibtex is basically LaTeX
|
|
|
|
'bibtex' => 'latex',
|
2016-02-03 22:33:39 +00:00
|
|
|
|
|
|
|
// 'emacs-lisp' was an alias for the Emacs Lisp lexer.
|
|
|
|
// It got dropped in Pygments commit 811926b, probably by accident.
|
|
|
|
// Declare it here until it is restored upstream.
|
|
|
|
// Upstream bug:
|
|
|
|
// https://bitbucket.org/birkenfeld/pygments-main/issues/1207
|
|
|
|
'emacs-lisp' => 'elisp',
|
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
|
|
|
);
|
|
|
|
|
|
|
|
public function __construct( $html ) {
|
|
|
|
$this->html = $html;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function error() {
|
|
|
|
}
|
|
|
|
|
|
|
|
public function set_language( $language ) {
|
|
|
|
}
|
|
|
|
|
|
|
|
public function parse_code() {
|
|
|
|
global $wgOut;
|
|
|
|
$wgOut->addModuleStyles( 'ext.pygments' );
|
|
|
|
return $this->html;
|
|
|
|
}
|
|
|
|
}
|