# Problems with highlight.js

Stack Exchange switched their syntax highlighting parser to highlight.js (announcement). This is a clear downgrade for TeX (for now). However, highlight.js is said to be "actively developed" which makes me hopeful that this can be resolved in the medium term.

This question can be used to collect issues with the new syntax highlighting and track progress on solving them. Please

1. post one answer per issue with a code snipped showing the problem,
2. create an issue on highligh.js' Github page and
3. mark the problem as solved in the answer when it has been resolved.

While this is really, really annoying, I believe it could also be an opportunity. The source file for the highlight.js LaTeX highlighting looks rather rudimentary, so we might be able to "take over" and improve it to our liking, maybe even improving some aspects of the old highlighting. I will try to find some time to get to know their system and see if I can't do that myself. Who knows, maybe we can finally get the LaTeX3 highlighting (as a separate language) I have been dreaming of..
• Is “everything” a valid answer? ;-) – Phelype Oleinik Sep 25 '20 at 14:25
• @PhelypeOleinik I don't know. Why don't you try opening an issue on the Github about that.. ;-) – schtandard Sep 25 '20 at 14:33
• David added an answer on the main meta. Maybe it would be a good idea to collect the responses here into an answer there as well, that meta question seems to be monitored by the StackExchange engineer responsible for the new highlighter (given his responses to the question there), whereas I'm not sure he will pay attention to our own meta. – Marijn Sep 26 '20 at 11:13
• Note also that it is currently unclear how often StackExchange will update their version of Highlight.js, so it could be the case that an issue is fixed in a new version but we are stuck on the site with an older version for some time. – Marijn Sep 26 '20 at 11:53
• There has been an update, everything is blue now :) – Marijn Nov 19 '20 at 20:04

## There is (usually) no syntax highlighting inside braces

[fixed in highlight.js 10.3]

Sample:

\foo{\foo\bar \\\\\baz}


Github issue

• I am totally agree with you. – Sebastiano Sep 25 '20 at 18:49
• Now it has been changed the color: there is a light green color. – Sebastiano Sep 25 '20 at 19:56

## Backslashes are not highlighted as part of the control sequence

[fixed in highlight.js 10.3]

Sample:

\foo\bar \\\\\baz


Github issue

• Many compliments for the question on Github. – Sebastiano Sep 25 '20 at 18:50

## @ ("at") isn't recognized as a valid character in a command name

[fixed in highlight.js 10.3]

Many hundreds (thousands?) of LaTeX2 commands employ the @ character in their names -- usually after one issues an explicit or implicit \makeatletter directive. Consider the following example (taken from an old answer of mine):

\makeatletter
\renewcommand\p@subsection{\thesection}
\renewcommand\p@subsubsection{\p@subsection\thesubsection}
\makeatother


If coloring of macro names is to be performed at all, it is crucial that the coloring scheme be informed that @ can be a valid character in command names.

## Incorrect identification of scope of a macro definition

[fixed in highlight.js 10.3 (no such identification takes place)]

Consider the following example

\newcommand\sorted[1]{\directlua{sorted(\luastringN{#1})}}


Observe that the final three characters -- )}} -- aren't colored green even though they clearly belong to the scope of the argument of the \sorted macro.

The remedy would be not to look for the very first instance of } but for instance that matches the opening { character.

## Very difficult to distinguish comments from ordinary text.

Consider

Hello World. % A comment.


The shade of gray that's used to highlight what's a comment is quite dark, making it anything but straightforward to identify comments visually. Please reinstate the old scheme, which used a much lighter shade of gray to denote comments.

• This is not really the domain of highlight.js, as the colors are set by Stack Exchange. It can be discussed in this question, though. – schtandard Oct 17 '20 at 19:05

## LaTeX3-semantics for valid macro names aren't recognized.

[fixed in highlight.js 10.3]

With LaTeX3, the characters _ (underscore) and : (colon) may be (in fact, must be) used in various macro names. Take the following code snippet:

\seq_set_eq:NN \l__ralph_seq \l__alph_seq
\seq_set_eq:NN \l__rAlph_seq \l__Alph_seq
\seq_set_eq:NN \l__ralphAlph_seq \l__alphAlph_seq
\seq_set_eq:NN \l__rAlphalph_seq \l__Alphalph_seq
\seq_reverse:N \l__ralph_seq
\seq_reverse:N \l__rAlph_seq
\seq_reverse:N \l__ralphAlph_seq
\seq_reverse:N \l__rAlphalph_seq
\seq_set_eq:NN \l__custom_order_seq \l__Alphalph_seq


Because the new coloring scheme is evidently unaware of the uses of : and _ in command names, the scheme makes it very hard to figure out what's going on.

• That's how it was with the old syntax highlighting, too, though, isn't it? – schtandard Sep 27 '20 at 9:42
• Also, I don't think these should be treated as letters by default. I math contexts it is quite common to have something like \theta_a, which would then be misinterpreted as one command sequence. – schtandard Sep 27 '20 at 9:45
• @schtandard - I don't have the screenshots needed to prove this claim definitively, but I seem to remember that most macro names were not color-coded -- just declarative commands such as \documentclass, \newcommand, \begin, and \end got the treatment. – Mico Sep 27 '20 at 10:12

## Incorrect display of array or tabular parameters when there is @{}

[fixed in highlight.js 10.3 (no such identification takes place)]

    \begin{array}{c@{}cc}
a & b & c\\
d & e & f
\end{array}
\begin{tabular}{c@{}cc}
a & b & c\\
d & e & f
\end{tabular}


In the above examples {c@{} is green whereas cc} is black.

• This is the same issue as with macro parameters in general. highlight.js just terminates any brace group at the first closing bracer, disregarding the possibility of nesting. – schtandard Oct 22 '20 at 6:36
• @schtandard OK, should I delete my answer? – CarLaTeX Oct 22 '20 at 6:57
• Not for my sake. Having it here doesn't do any harm. :-) – schtandard Oct 22 '20 at 7:27
• @schtandard Thank, I let it here in case others see the same problem. – CarLaTeX Oct 22 '20 at 8:38