Minted compatibility patch

[jfbu]

LaTeX: workaround to ensure compatibility with minted

This reverts already merged #1735 (after a commit from #1736 to fix it)
and applies the first envisioned method discussed in #1734.

The reason is that the #1735-#1736 method only partially repairs the
minted compatibility. Minted queries from Pygments the stylesheet
with a command prefix equal to the style name, which may contain
(at least, so far) characters such as - and _, which are not normally
allowed in LaTeX macros. So it modifies the meaning of - and _ before
telling LaTeX to input the Pygments provided stylesheet. Restoring
the normal meaning of - from inside the stylesheet must be carefully
localized: at top and bottom of stylesheets some macros will use in
their names the - and there the - must be the weird minted one, not
the normal one.

The #1735-#1736 method thus does fix compatibility with minted but only
for those style names not using a -, but it creates another issue if
used with e.g. style "paraiso-dark" which has a - character in its name.

"De guerre lasse", I feel it is simpler to use the somewhat strange
very localized hotfix of prefixing - by \string at the one spot where
we need it to be its normal self. Hence this PR.

Fix #1734.

Relates: gpoore/minted#294

I was not familiar with minted LaTeX code. It has taken me some time to understand what is involved (and on this occasion I discovered that with LaTeX of spring 2021, loading a file results in a log trace in about 10000 (!!) macro calls to the LaTeX3 syntax in the minted context so it is nowadays extremely laborious to examine a LaTeX problem via \tracingmacros1.).

The good thing in minted approach is that it uses weird command prefix only to recover the stylesheet. Regarding actual mark-up for highlighting code it uses \PYG default prefix. So the catcode issues are, fortunately, localized to only actually loading the stylesheet for a given stylename.

Although minted will probably get an upgrade, many people will be for some time with its current version. So, despite this being entirely a design problem on minted side, it must be fixed on Pygments side. It is very ugly to add this \string like I do, but this works and solves the problem, as identified so far.

[Anteru]

Thanks! I can't tell that I fully understand what is going on here :) I've applied #1735 and #1737 to both master and the release branch, and I understand your PRs correctly that's all that is needed. Can you please confirm before we prepare another release?

[jfbu]

Can you please confirm before we prepare another release?

I checked the diff for pygments/formatters/latex.py with 2.8.0 on 2.8.x and master, and it correctly indicates replacement of -\fboxrule by \string -\fboxrule.

So yes, this should fix the issue (also for styles such as paraiso-dark) in a way robust against upstream minted changes. The \string is core TeX syntax to convert the following control sequence to a name, or to convert the following character to have "catcode 12", which is the normal for digits, +, - , ..., and they must be this way for usage in dimension assignments. Fortunately even with calc package loaded which complicates \setlength, the parsing done by calc is gentle enough for \string action to not be inhibited.

I tested with this (which contains non-sense to try to trigger the \PYG{err} which in some styles does a border; this is not a full test but I hope it is confirmation enough)

\documentclass{article}
\usepackage{minted}

\begin{document}

\begin{minted}{http}
abc
\end{minted}

\begin{minted}[style=paraiso-dark]{http}
abc-xyz: -22
\end{minted}

\begin{minted}[style=algol_nu]{http}
abc-xyz: -22
\end{minted}

\begin{minted}[style=paraiso-dark]{python}
-x = def a && b
\end{minted}

\end{document}

[Anteru]

Thanks a lot for checking & the detailed explanation, much appreciated!