Extension talk:SyntaxHighlight/Archive 2016

2016

Add support for new langages

I would like to add support for new langages like XAML.
I expected to find a folder named lexers in /extensions/SyntaxHighlight_GeSHi/pygments, but there is no folder like that.
Could anyone explain me where to add the new lexer files and the procedure to register them?
NikusPokus (talk) 11:31, 19 June 2016 (UTC)

I wasn't able to figure out how to do this with the bundled version of pygments, but I was able to do this using a custom "pygmentize" install.

On Linux, install python and download the source code install for pygments. Compile and install your custom version of pygementize: python setup.py install

In LocalSettings.php, set $wgPygmentizePath to the location of your custom version of pygmentize: $wgPygmentizePath = '/usr/local/bin/pygmentize';

Find where the pygments package was installed. On my system (Ubuntu) it was at /usr/local/lib/python2.7/dist-packages/Pygments-2.1.3-py2.7.egg/pygments

In that folder, there should be a lexers folder where you can add a new lexer, see pygments.org for information on how to create one. Once it has been created, register your new lexer with pygments by changing into the lexers folder and running the _mapping.py program from within that folder. Then, to register the new lexer with SyntaxHighlight, run updateLexerList.php in the extensions/SyntaxHighlight_GeSHi/maintenance folder. Now, you should be able to use your new language on your wiki.

As an aside, if you want to change the colors for the highlighted object, go into the styles folder. SyntaxHighlight uses the default style, so you need to edit default.py. Then, to register your changes with SyntaxHighlight, run the updateCSS.php maintenance app. -- Zoltair 08:23, 23 Jul 2016

@Zoltair, thanks for your answer. I expected to add a new lexer in the bundled version of pygments, but thanks to your feedback I switched to the installation of Pygments instead. Thanks to your explanations I managed to register a new lexer in my MediaWiki website! NikusPokus (talk) 17:15, 29 July 2016 (UTC)

selecting code also selects line number, and the CSS fix doesn't seem to work

In my version 2.0 (822ede6), selecting code also selects the line number. This makes it hard to use the code you have copied. the solution here, .mw-highlight .lineno { user-select:none; } on Mediawiki:Common.css, doesn't seem to work. Billmackenty (talk) 08:59, 11 March 2016 (UTC)

At a quick glance, the CSS classes look like they should also be working with the new version... --87.123.61.63 22:40, 31 March 2016 (UTC)

e

w:en:E (programming language) is listed as currenty supported, but I don’t see an e downstream nor an entry in the Pygments lexer list. Greetings --PerfektesChaos (talk) 14:10, 13 March 2016 (UTC)

I have updated the page accordingly. If you need E support, you might be able to use a custom version of Pygments (an own wheel file). The right way, however, is to get an E lexer integrated into the upstream version of Pygments. --87.123.61.63 22:35, 31 March 2016 (UTC)

Example for a language definition

My text editor KeditW (an XEDIT-clone) offers syntax highlighting based on KLD-files (Kedit Language Definitions), and it's fun to create new KLD-files. So far I have created "good enough" (for me) KLDs for BATCH (Windows NT bat/cmd), FREECIV (an INI-variant for rulesets/tilesets/etc.), and WASM (Watcom assembler). Now I'm curious if the BATCH + WASM stuff might be also useful here, please add some example links to raw language definitions (apparently known as pygments lexers), and a recipe (ideally less than 5min reading time ) how and where to test and submit a new language. Be..anyone (talk) 07:29, 6 April 2016 (UTC)

Supported languages

Code	Language (see listing)	change to	example
bnf	Backus–Naur Form	active	<Programm> ::= 'PROGRAM' <Bezeichner> 'BEGIN' <Satzfolge> 'END' . <Bezeichner> ::= <Buchstabe> <Restbezeichner> <Restbezeichner> ::= | <Buchstabe oder Ziffer> <Restbezeichner> <Buchstabe oder Ziffer> ::= <Buchstabe> | <Ziffer> <Buchstabe> ::= A | B | C | D | … | Z | a | b | … | z <Ziffer> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 <Satzfolge> ::= … …
dcl	Data Control Language		GRANT Operation+ ON Relation TO (PUBLIC|Benutzer) [WITH GRANT OPTION] REVOKE Operation+ ON Relation FROM (PUBLIC|Benutzer)
cfdg	CFDG	strike out
div	DIV
euphoria	Euphoria
genero	Genero
oz	Oz
spark	SPARK

Please actualize the listing. --Lómelinde (talk) 08:55, 10 April 2016 (UTC)

Indent oddity

On my commons user page and here I use SyntaxHighlight for a very simple JavaScript example. Oddly I had to modify the indent of one line in the source to get the intended effect with SyntaxHighlight, diffs: 1, 2. –Be..anyone 💩 12:07, 17 April 2016 (UTC)

Add Template Usage to the Extension Page

This extension can be used within a template by using the magic word #tag:

{{#tag:syntaxhighlight | {{{param}}} | lang=xxx }}

You can also use it inline (have to use the backwards compatible option, since #tag doesn't allow for one-part attributes from what I can see)

{{#tag:syntaxhighlight | {{{param}}} | lang=xxx | enclose=none }}

It took me a good hour to figure this out, it should be added to the main page, maybe in the Usage section. --Chazbot7 (talk) 19:29, 17 May 2016 (UTC)

Default Language in 1.26

Previously, there was a $wgSyntaxHighlightDefaultLang setting. Now there's a $wgSyntaxHighlightModels setting, but I don't know whether this can be used to set a default language for normal content pages. There doesn't seem to be any documentation for it. Does anyone know more about it? -- kelunik . . (Talk | Contribs) 15:03, 29 May 2016 (UTC)

Have a look into the code! This is the only place, where $wgSyntaxHighlightModels is used. Feel free to update the extension page with more information on this variable! --87.123.34.155 18:08, 28 August 2016 (UTC)

Collapsible elements not working

When I enable SyntaxHighlight_GeSHi in LocalSettings.php the collapsible items in my mediaWiki no longer collaps! - Did anybody experience the same? Did you find a solution?

Example:

 <div class="toccolours mw-collapsible mw-collapsed" style="width:600px">
 '''Collapsible box'''
 <div class="mw-collapsible-content">
 Text
 </div></div>

Sohansenit (talk) 11:53, 30 June 2016 (UTC)

Extension doesn't work after updating from 1.22.13 to 1.27.

Extension worked fine at the MW 1.22.13, after updating all pages marked as "Pages with syntax highlighting errors". What shall I do first of all?

I had a similar problem on windows going from 1.24 to 1.27

To resolve

1. install GeSHI from MASTER and not the 1.27
2. installing Pygmentize in python
3. specify $wgPygmentizePath = "c:\\Python27\\Scripts\\pygmentize.exe";

The reason for these problems most likely is the missing language support in Pygments. The master branch of SyntaxHighlight contains a very recent version of Pygments, which already supports a number of languages, which had been missing in MW 1.26. However, there still are quite a few missing ones. --87.123.34.155 18:04, 28 August 2016 (UTC)

I had this same issue, but managed to fix it. In my LocalSettings.php, I originally had $wgMainCacheType = CACHE_ACCEL;, and I then changed it to $wgMainCacheType = CACHE_DB;. After this change, syntax highlights are now displayed properly and the "Pages with syntax highlighting errors" markings all disappeared.

SyntaxHighlight lang tegs dont work in MW 1.27.1

Updated my MW 1.27.0 to 1.27.1 and now dont work tegs: <syntaxhighlight lang="language_name">

Only work: <syntaxhighlight>

How fix?

Had same problem on fresh install 1.27.1 on Ubuntu 16.04. Solution:

• sudo apt-get install python python-pip
• sudo -H pip install --upgrade pip
• sudo -H pip install --upgrade virtualenv
• sudo -H pip install Pygments
• In LocalSettings.php, set wgPygmentizePath = '/usr/local/bin/pygmentize';

Worked like a charm.

Can the extension support wiki synatax?

eg. template syntax?--Gqqnb (talk) 19:19, 11 September 2016 (UTC)

After upgrade the mediawiki from 1.22.7 to 1.27.1 SyntaxHighlight is not working

Here is the details : Wiki is under private network. using Linux, mysql , php Please help me to resolve this.

Make sure to set executable permissions on pygments. -- Prod (talk) 05:06, 15 September 2016 (UTC)

Thanks It is working fine :)

$wgSyntaxHighlightModels config examples?

The page says that you can use $wgSyntaxHighlightModels to configure more languages, but doesn't explain how exactly, or what the format should be. I was not able to easily find this anywhere else either. Can someone add an explanation, or a link to another relevant doc page? —Ynhockey (talk) 15:27, 28 September 2016 (UTC)

Optionally use HTTP-CGI proxy over Pygments or keep the support for old GeSHi-based version for newer MediaWiki engines (where proc_open() is disabled by hosting providers)

The main reason I still use old GeSHi-based version of the extension (for MediaWiki 1.25) even I had MediaWiki 1.27 (and just now I have been upgraded to 1.28) is limitations of virtual hosting providers where there are disabling PHP functions like proc_open() for security reasons which make impossible to use the Pygments utility, and highlighter is not working. But now since I have been upgraded to 1.28, old extension no more works. Also, old version kills the WikiEditor (since 1.27) and I have a plain-text editor without a toolbar. A new version has no those issues, and that great. But I'm not able to use it because of proc_open() and other functions are disabled by hosting provider.

• I have my own dedicated server which I'm able to use for hosting (which I using for sites targeted to my country). The reason why I using a virtual hosting provider for international projects is an availability of my server from the world (in Europe data sending quick, but in America, China, and Australia it is very slow). Virtual hosting resolves this trouble.
• VPS even resolves everything, it is too expressive in comparison with a virtual hosting (which now provides me with 30 GB disk space and with the everything), and even in comparison with maintaining of my own server which gives me 1 TB space, quad-core CPU with 3.6 GHz and 8 GB RAM and 100 MBps connection which is much cheaper to maintain (just pay ~ $24 (converted into dollars from my local currency, which I measured how much my server eats kWph and how much this will cost) per month for electricity and $9,86 per month for Internet access with a static IP-address, and very rare pay for the upgrading of a hardware). The reason why I'm not using the own server for international projects I explained above.

The suggestions how to resolve this trouble I can give:

• Upgrade old GeSHi-based version to support new MediaWiki engines (hard way)
• Implement an optional proxy to use Pygments as CGI/FastCGI application through HTTP(S) instead of direct executing of the Pygments binary. (Easier way, because is possible to convert the HTTP-Get/Post/Put requests into $0, $1, $2, etc. by overriding).

Vdnovichkov (talk) 14:35, 26 December 2016 (UTC)

EDIT: I just made a small proxy for that: (just put it together with Pygmentize utility into "cgi-bin", then pass through HTTP GET/POST a command line parameters "params" (a space separated arguments, yet) and input data in the "indata"). Note: It's just an example, and I'm C++/PHP programmer and python is not my language. I hope you or some other will make better and safe proxy. This may be insecure because of no any filtering or input. But because every argument is passed individually and pre-filtered by "Popen" separately, must don't cause any security issues.

#!/usr/bin/python
from subprocess import Popen, PIPE
import cgi

form = cgi.FieldStorage()

print "Content-type: text/plain;\r\n\r\n"
args = form.getvalue("params")
argsArr = args.split()
argsArr.insert(0, "./pygmentize")

p = Popen(argsArr, stdin=PIPE, stdout=PIPE, stderr=PIPE)
output, err = p.communicate(form.getvalue("indata"))
rc = p.returncode

print output
# print err

Vdnovichkov (talk) 15:11, 26 December 2016 (UTC)

P.S. Maybe encode output as JSON to be able to retrieve any error output and exit code to be able to identify any possible errors. Vdnovichkov (talk) 15:21, 26 December 2016 (UTC)