Extension talk:SyntaxHighlight

• Extension talk:SyntaxHighlight/REL1.25 (LTS)

Previous discussion was archived at Extension talk:SyntaxHighlight/Archive 2017 on 2017-03-29.

The list of languages is currently a mess. There's a yellow box showing a single April 2023 addition, a main list that's current as of 2020, and a blue box showing some 2021 additions. I propose replacing all of that with the following, which was derived from https://github.com/pygments/pygments/blob/release/2.17.x/pygments/lexers/_mapping.py (Pygments 2.17.2 is the latest version deployed to Wikimedia wikis as of December 2023):

• abap
• amdgpu
• apl
• abnf
• actionscript3
  • as3
• actionscript
  • as
• ada
  • ada95
  • ada2005
• adl
• agda
• aheui
• alloy
• ambienttalk
  • ambienttalk/2
  • at
• ampl
• html+ng2
• ng2
• antlr-actionscript
  • antlr-as
• antlr-csharp
  • antlr-c#
• antlr-cpp
• antlr-java
• antlr
• antlr-objc
• antlr-perl
• antlr-python
• antlr-ruby
  • antlr-rb
• apacheconf
  • aconf
  • apache
• applescript
• arduino
• arrow
• arturo
  • art
• asc
  • pem
• asn1
• aspectj
• asymptote
  • asy
• augeas
• autoit
• autohotkey
  • ahk
• awk
  • gawk
  • mawk
  • nawk
• bbcbasic
• bbcode
• bc
• bqn
• bst
  • bst-pybtex
• bare
• basemake
• bash
  • sh
  • ksh
  • zsh
  • shell
• console
  • shell-session
• batch
  • bat
  • dosbatch
  • winbatch
• bdd
• befunge
• berry
  • be
• bibtex
  • bib
• blitzbasic
  • b3d
  • bplus
• blitzmax
  • bmax
• blueprint
• bnf
• boa
• boo
• boogie
• brainfuck
  • bf
• bugs
  • winbugs
  • openbugs
• camkes
  • idl4
• c
• cmake
• c-objdump
• cpsa
• css+ul4
• aspx-cs
• csharp
  • c#
  • cs
• ca65
• cadl
• capdl
• capnp
• carbon
• cbmbas
• cddl
• ceylon
• cfengine3
  • cf3
• chaiscript
  • chai
• chapel
  • chpl
• charmci
• html+cheetah
  • html+spitfire
  • htmlcheetah
• javascript+cheetah
  • js+cheetah
  • javascript+spitfire
  • js+spitfire
• cheetah
  • spitfire
• xml+cheetah
  • xml+spitfire
• cirru
• clay
• clean
• clojure
  • clj
• clojurescript
  • cljs
• cobolfree
• cobol
• coffeescript
  • coffee-script
  • coffee
• cfc
• cfm
• cfs
• comal
  • comal80
• common-lisp
  • cl
  • lisp
• componentpascal
  • cp
• coq
• cplint
• cpp
  • c++
• cpp-objdump
  • c++-objdumb
  • cxx-objdump
• crmsh
  • pcmk
• croc
• cryptol
  • cry
• cr
  • crystal
• csound-document
  • csound-csd
• csound
  • csound-orc
• csound-score
  • csound-sco
• css+django
  • css+jinja
• css+ruby
  • css+erb
• css+genshitext
  • css+genshi
• css
• css+php
• css+smarty
• cuda
  • cu
• cypher
• cython
  • pyx
  • pyrex
• d
• d-objdump
• dpatch
• dart
• dasm16
• dax
• debcontrol
  • control
• delphi
  • pas
  • pascal
  • objectpascal
• desktop
• devicetree
  • dts
• dg
• diff
  • udiff
• django
  • jinja
• zone
• docker
  • dockerfile
• dtd
• duel
  • jbst
  • jsonml+bst
• dylan-console
  • dylan-repl
• dylan
• dylan-lid
  • lid
• ecl
• ec
• earl-grey
  • earlgrey
  • eg
• easytrieve
• ebnf
• eiffel
• iex
• elixir
  • ex
  • exs
• elm
• elpi
• emacs-lisp
  • elisp
  • emacs
• email
  • eml
• erb
• erlang
• erl
• html+evoque
• evoque
• xml+evoque
• execline
• ezhil
• fsharp
  • f#
• fstar
• factor
• fancy
  • fy
• fan
• felix
  • flx
• fennel
  • fnl
• fift
  • fif
• fish
  • fishshell
• flatline
• floscript
  • flo
• forth
• fortranfixed
• fortran
  • f90
• foxpro
  • vfp
  • clipper
  • xbase
• freefem
• func
  • fc
• futhark
• gap-console
  • gap-repl
• gap
• gdscript
  • gd
• glsl
• gsql
• gas
  • asm
• gcode
• genshi
  • kid
  • xml+genshi
  • xml+kid
• genshitext
• pot
  • po
• gherkin
  • cucumber
• gnuplot
• go
  • golang
• golo
• gooddata-cl
• gosu
• gst
• graphql
• graphviz
  • dot
• groff
  • nroff
  • man
• groovy
• hlsl
• html+ul4
• haml
• html+handlebars
• handlebars
• haskell
  • hs
• haxe
  • hxsl
  • hx
• hexdump
• hsail
  • hsa
• hspec
• html+django
  • html+jinja
  • htmldjango
• html+genshi
  • html+kid
• html
• html+php
• html+smarty
• http
• haxeml
  • hxml
• hylang
• hybris
  • hy
• idl
• icon
• idris
  • idr
• igor
  • igorpro
• inform6
  • i6
• i6t
• inform7
  • i7
• ini
  • cfg
  • dosini
• io
• ioke
  • ik
• irc
• isabelle
• j
• jmespath
  • jp
• jslt
• jags
• jasmin
  • jasminxt
• java
• javascript+django
  • js+django
  • javascript+jinja
  • js+jinja
• javascript+ruby
  • js+ruby
  • javascript+erb
  • js+erb
• js+genshitext
  • js+genshi
  • javascript+genshitext
  • javascript+genshi
• javascript
  • js
• javascript+php
  • js+php
• javascript+smarty
  • js+smarty
• js+ul4
• jcl
• jsgf
• jsonld
  • json-ld
• json
  • json-object
• jsonnet
• jsp
• jsx
  • react
• jlcon
  • julia-repl
• julia
  • jl
• juttle
• k
• kal
• kconfig
  • menuconfig
  • linux-config
  • kernel-config
• kmsg
  • dmesg
• koka
• kotlin
• kuin
• kql
  • kusto
• lsl
• css+lasso
• html+lasso
• javascript+lasso
  • js+lasso
• lasso
  • lassoscript
• xml+lasso
• ldapconf
  • ldaprc
• ldif
• lean
  • lean3
• less
• lighttpd
  • lighty
• lilypond
• limbo
• liquid
• literate-agda
  • lagda
• literate-cryptol
  • lcryptol
  • lcry
• literate-haskell
  • lhaskell
  • lhs
• literate-idris
  • lidris
  • lidr
• livescript
  • live-script
• llvm
• llvm-mir-body
• llvm-mir
• logos
• logtalk
• lua
• mcfunction
  • mcf
• mcschema
• mime
• mips
• moocode
  • moo
• doscon
• macaulay2
• make
  • makefile
  • mf
  • bsdmake
• css+mako
• html+mako
• javascript+mako
  • js+mako
• mako
• xml+mako
• maql
• markdown
  • md
• mask
• mason
• mathematica
  • mma
  • nb
• matlab
• matlabsession
• maxima
  • macsyma
• meson
  • meson.build
• minid
• miniscript
  • ms
• modelica
• modula2
  • m2
• trac-wiki
  • moin
• monkey
• monte
• moonscript
  • moon
• mosel
• css+mozpreproc
• mozhashpreproc
• javascript+mozpreproc
• mozpercentpreproc
• xul+mozpreproc
• mql
  • mq4
  • mq5
  • mql4
  • mql5
• mscgen
  • msc
• mupad
• mxml
• mysql
• css+myghty
• html+myghty
• javascript+myghty
  • js+myghty
• myghty
• xml+myghty
• ncl
• nsis
  • nsi
  • nsh
• nasm
• objdump-nasm
• nemerle
• nesc
• nestedtext
  • nt
• newlisp
• newspeak
• nginx
• nimrod
  • nim
• nit
• nixos
  • nix
• nodejsrepl
• notmuch
• nusmv
• numpy
• objdump
• objective-c
  • objectivec
  • obj-c
  • objc
• objective-c++
  • objectivec++
  • obj-c++
  • objc++
• objective-j
  • objectivej
  • obj-j
  • objj
• ocaml
• octave
• odin
• omg-idl
• ooc
• opa
• openedge
  • abl
  • progress
• openscad
• output
• pacmanconf
• pan
• parasail
• pawn
• peg
• perl6
  • pl6
  • raku
• perl
  • pl
• phix
• php
  • php3
  • php4
  • php5
• pig
• pike
• pkgconfig
• plpgsql
• pointless
• pony
• portugol
• postscript
  • postscr
• psql
  • postgresql-console
  • postgres-console
• postgres-explain
• postgresql
  • postgres
• pov
• powershell
  • pwsh
  • posh
  • ps1
  • psm1
• pwsh-session
  • ps1con
• praat
• procfile
• prolog
• promql
• properties
  • jproperties
• protobuf
  • proto
• prql
• psysh
• ptx
• pug
  • jade
• puppet
• pypylog
  • pypy
• python2
  • py2
• py2tb
• pycon
• python
  • py
  • sage
  • python3
  • py3
  • bazel
  • starlark
• pytb
  • py3tb
• py+ul4
• qbasic
  • basic
• q
• qvto
  • qvt
• qlik
  • qlikview
  • qliksense
  • qlikscript
• qml
  • qbs
• rconsole
  • rout
• rng-compact
  • rnc
• spec
• racket
  • rkt
• ragel-c
• ragel-cpp
• ragel-d
• ragel-em
• ragel-java
• ragel
• ragel-objc
• ragel-ruby
  • ragel-rb
• rd
• reasonml
  • reason
• rebol
• red
  • red/system
• redcode
• registry
• resourcebundle
  • resource
• rexx
  • arexx
• rhtml
  • html+erb
  • html+ruby
• ride
• rita
• roboconf-graph
• roboconf-instances
• robotframework
• rql
• rsl
• restructuredtext
  • rst
  • rest
• trafficscript
  • rts
• rbcon
  • irb
• ruby
  • rb
  • duby
• rust
  • rs
• sas
• splus
  • s
  • r
• sml
• snbt
• sarl
• sass
• savi
• scala
• scaml
• scdoc
  • scd
• scheme
  • scm
• scilab
• scss
• sed
  • gsed
  • ssed
• shexc
  • shex
• shen
• sieve
• silver
• singularity
• slash
• slim
• slurm
  • sbatch
• smali
• smalltalk
  • squeak
  • st
• sgf
• smarty
• smithy
• snobol
• snowball
• solidity
• sophia
• sp
• debsources
  • sourceslist
  • sources.list
• sparql
• spice
  • spicelang
• sql+jinja
• sql
• sqlite3
• squidconf
  • squid.conf
  • squid
• srcinfo
• ssp
• stan
• stata
  • do
• supercollider
  • sc
• swift
• swig
• systemverilog
  • sv
• systemd
• tap
• tnt
• toml
• tads3
• tal
  • uxntal
• tasm
• tcl
• tcsh
  • csh
• tcshcon
• tea
• teal
• teratermmacro
  • teraterm
  • ttl
• termcap
• terminfo
• terraform
  • tf
  • hcl
• tex
  • latex
• text
• ti
  • thingsdb
• thrift
• tid
• tlb
• tls
• todotxt
• tsql
  • t-sql
• treetop
• turtle
• html+twig
• twig
• typescript
  • ts
• typoscriptcssdata
• typoscripthtmldata
• typoscript
• ul4
• ucode
• unicon
• unixconfig
  • linuxconfig
• urbiscript
• urlencoded
• usd
  • usda
• vbscript
• vcl
• vclsnippets
  • vclsnippet
• vctreestatus
• vgl
• vala
  • vapi
• aspx-vb
• vb.net
  • vbnet
  • lobas
  • oobas
  • sobas
• html+velocity
• velocity
• xml+velocity
• verifpal
• verilog
  • v
• vhdl
• vim
• visualprologgrammar
• visualprolog
• vyper
• wdiff
• wast
  • wat
• webidl
• wgsl
• whiley
• wikitext
  • mediawiki
• wowtoc
• wren
• x10
  • xten
• xml+ul4
• xquery
  • xqy
  • xq
  • xql
  • xqm
• xml+django
  • xml+jinja
• xml+ruby
  • xml+erb
• xml
• xml+php
• xml+smarty
• xorg.conf
• xpp
  • x++
• xslt
• xtend
• extempore
• yaml+jinja
  • salt
  • sls
• yaml
• yang
• yara
  • yar
• zeek
  • bro
• zephir
• zig
• ansys
  • apdl

Hi good people

Really really new to MediaWiki, the software.

I want to optional use the pygments style dracula with some of my Syntaxhighlight entries on my wiki

So far I have found the -S option in includes/Pygmentize.php but this of course changes it for all usage of SyntaxHighlight so my next approach was to add a parameter pstyle to SyntaxHighlight and choose when to use it . But I am unclear how to pass something to updateCSS.php

<syntaxhighlight lang="cpp" pstyle="dracula">

int main(int a, char* args[]) {

// Test

  return 0;

}

</syntaxhighlight>

Template:Codesample shows one way to use TemplateStyles to apply custom CSS to SyntaxHighlight output.

Hello, I am reading everywhere it is not possible to embed links into code blocks.

However, I have seen it being done on cppreference.com, and they also use this extension, so there must be some hack or something.

I don't mind if I have to update something inside the extension.

By definition any content than </syntaxhighlight> will be produced as regular text on wiki page.

• However, people might post-process the result of this extension.
• They could interact on server side with the API of the pygments software.
• They could manipulate the generated HTML document on client side by JavaScript, identifying interesting things like URL and link those URL, or other connected formats and identified items. Every token is an HTML element equipped with a class, which makes it easy to find certain types of items, analyse this text and replace the plain text content by a HTML link to somewhere.
• You might even try to integrate HTML link generation into your language.

Greetings

Ah got it, so I won't get around writing my own extension.

Thanks for the elaborate answer, appreciate it. :)

cppreference.com is running a version of MediaWiki and SyntaxHighlight from 2013, so feature comparisons are questionable in any case. The version of SyntaxHighlight in use there would have still used GeSHi as the highlighting engine. The modern extension uses Pygments which is not only a different implementation, it is also written in a different programming language.

Example for JavaScript postprocessing:

• de:Hilfe:Textgestaltung/HTML
• Find all elements (which should be descendants of the <syntaxhighlight> blocks) which match the span.nt selector.
• Read the content of the span, create an URL to a website explaining HTML elements, linking this particular tag name. Wrap the span into an a href="" element.

Enjoy

Is it possible to format text within syntaxhighlight? I would like to keep this italicization of "parameter1", while syntaxhighlighting "Template name":

{{Template name|parameter1}}

  ~ Tom.Reding (talk ⋅ )  11:31, 28 July 2024 (UTC)

I don’t think so. The purpose of syntax highlighting is that it highlights syntax rather than interpreting it. How would it know what to highlight ({{) and what to interpret ('')?

By the way, if the template is really that simple (just a template name and one or a few parameters), IMHO syntax highlighting is unnecessary: it makes the code block stand out too much (color really stands out) without helping much understanding it.

https://uoalive.com/wiki/Special:Version

Versions are all correct, dependencies installed.

But not loading visual pygments

https://uoalive.com/wiki/MediaWiki:Common.css

The rendered HTML for your Common.css page indicates that SyntaxHighlight did not successfully run. If it had, within the <pre> child of the <div class="mw-highlight ..."> element there would be a large number of <span> elements wrapping various syntactical constructs of the CSS content.

There could be a number of issues causing this failure:

• /path/to/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize script not marked as executable
• No python3 interpreter in the PHP runtime's PATH
• PHP runtime configured to disable shell_exec
• Other things I'm not thinking of right now...

None of these would prevent Special:Version from showing the extension as installed or using the version of pygments bundled in the extension. There should however be some error logging via wfWarn that says something like "Failed to invoke Pygments: ..." or "Invoking Pygments returned blank output with no error response". See Manual:How to debug#Logging for help on configuring your wiki to write debug logs to a file where you can examine them.

It looks like my host doesn't have luasandbox installed and won't so that is likely it.

Hi there!

This talk page is insanely long, so bear with me if my question has already been answered (a quick search revealed nothing).

I'm editing a MediaWiki installation where I have no access whatsoever to its configuration, not to mention its actual files. Thus, I'm looking for a user-centred solution to this apparently simple issue: how to use different colour highlights?

Let me try to explain better. With the highlight parameter, we have the option of selecting whatever lines (even blocks of lines) we wish — but the highlighting colour is always the same (default seems to be 'marker yellow').

However, in the wiki I'm editing, one of the users requires explaining how different areas of the code work together, using different colours to highlight different sections. This is actually something I have seen in several examples elsewhere (not on wikis, mind you!) and is not uncommon in certain academic environments, to attract the student's attention to how some parts of the code connect to others.

I wonder, therefore, if such a functionality is possible using the current implementation of the SyntaxHighlight extension, or if it's the kind of thing that would require either a rewriting of the code (e.g., by adding extra parameters/attributes to the <syntaxhighlight> tag), the CSS file associated with a particular page, etc. Or if this is something already built-in (Pygments, at least, doesn't mention it, so it would be something developed on top of it, at the extension level itself), how could it be triggered?

A few alternatives, of course, come to mind, namely, stopping the flow of execution inside a <syntaxhighlight> block (possibly using one of those {{#tag}} blocks which seem to be so popular to 'fix' certain aspects of the rendering procedure) so that, say, the next line gets a different background colour from the standard yellowish one. I can conceive of a few ideas on how that could be implemented, but I'm not really sure how to apply them (I need to learn a bit more about #tag, too, and see if I have access to it on the wiki I'm working). So, hopefully, someone reads this and answers with a one-liner trick to get it working :)

Thank you all in advance for whatever insights you might share!

It is possible to use Extension:TemplateStyles to inject CSS into a page that alters colors for content marked up by SyntaxHighlight. Template:Codesample is one example of this. hll is the CSS class applied to highlighted lines.

There is not currently any mechanism to add additional CSS classes or ids to individual lines/ranges of lines highlighted via the highlight=... attribute. This would be necessary to allow you then target each line/range of lines with a different color via CSS.

It may be possible to approximate your desired solution by placing each highlighted line/range of lines in a separate <syntaxhighlight> tag on your page.

Another very hacky solution might be using styles like .hll:has(> .linenos[data-line="7"]) { background-color: purple} assuming you are also showing line numbers in the code blocks via the line attribute. TemplateStyles does not currently support the :has() pseudo-class, so this approach would need to use site wide CSS which makes it of very limited use.

I created this version using wikitext editing, and it had <syntaxhighlight inline lang="perl">use strict;</syntaxhighlight>. Note the inline attribute without any parameter.

Then I edited the page using VE. I only changed the content of the tag. When I saved, inline changed to inline="". Is that correct?

The final rendering is the same, but what is the right way to store the attribute code? The documentation at Extension:SyntaxHighlight has no parameter at all.

The PHP code only checks to see if an "inline" attribute has been provided in the tag definition. No check is done to see if there is an associated value or not. It is relatively common to see HTML linters that get confused about bare attributes like "selected" and "checked" to recommend `attribute="attribute"` usage. There is nothing technical wrong with VE using `attribute=""` in this similar situation.

It does sound like behavior that could be considered a dirty diff from parsoid round tripping.

In HTML, omitting the attribute value means exactly the same as setting it to the empty string. The legacy parser also treats them same when parsing extension tags (so there is no right way, both are equal and thus equally right); I suppose this is true for Parsoid as well.

(By the way, the comment in Sanitizer.php also notes that omitting the tag value is invalid in XHTML, so probably the linters that get confused are XHTML/XML linters, not real HTML linters.)

The page says: "This extension comes with MediaWiki 1.21 and above".

Does this mean that I can use the <syntaxhighlight> tag in something that another extension outputs and be sure that it will work?

Unfortunately, no. It just means that this extension is included in the Bundled extensions and skins tarball bundle. It still needs to be enabled in a wiki deployment's LocalSettings to be usable.

Re. the edit of 16 January 2024:

Hiya @Jdforrester (WMF): - in the edit you made, the unescaped <syntaxhighlight> tags were making the examples of the code render as the examples - I can't see a way to retain syntax highlighting while having the actual tags appear within the block of highlit code when created with normal tags (why would anyone ever need to escape characters between tags which are used to escape whole blocks of code?!) - the {{#tag:}} magic word works instead of the {{SyntaxHighlight source}} template, it looks a bit cleaner and it's how the page's other examples have done it, and like the template it will let its contents linewrap, which the raw tags don't - but I guess it looks similarly confusing in the source. Any suggestions for a better solution?

Yes, never mind, @Lou Montana reverted it in a later edit.

They only got one - there was a second starting at line 267

Forgot to set this as resolved from 8 months ago. Solution was to upgrade Pygments extension from 2.11.2 to 2.15.0.

Pygments lexers like "lua", "html", and "css" put pages using <syntaxhighlight> into "Category:Pages with syntax highlighting errors", despite these lexers being correct. Maybe there are other lexers causing this problem - I don't know. But the three I mentioned above are the ones I commonly use for template/module documentation.

I don't know why this happens. The wiki I contribute to runs on MediaWiki 1.39 with Extension:SyntaxHighlight version 2.0. The Pygments documentation states that these Short names: for the lexers I mentioned above are correct, so why are the pages that use them with <syntaxhighlight> placed in the tracking category?

Does anyone know?

Does the code get highlighted? (It’s always good to share a link so that I can answer such simple questions on my own.) The error category gets added whenever the highlighting is unsuccessful – this includes not only incorrect lexer names, but also when the code is too big or calling Pygments fails for any reason.

The code gets highlighted, so I don't know why pages using <syntaxhighlight> end up in the tracking category. There are pages in the tracking category for this wiki that use syntax highlighting correctly but still end up categorized.

Could you please provide a link? It’s very hard to debug without being able to see what exactly is happening.

I apologize for the 2-month late response User:Tacsipacsi. I tried replying sooner, but an error with Extension:StructuredDiscussions on MediaWiki was preventing me from entering a response about a month ago.

I just wanted to let you know that the lexers I defined 2 months ago as not working do work again. The pages on the wiki I contribute to no longer end up being incorrectly categorized under this extension's tracking category when using <syntaxhighlight> correctly.

This issue I had may have been fixed with a major version update to Pygments. During the time I had the categorization issue, this extension was using Pygments 2.11.2. It now uses Pygments 2.15.0 as of April 10 of this year (commit 9f9c13b).