# bug in pgfplots or other packages [duplicate]

This code lets pdflatex go into an infinite loop

\documentclass{scrbook}

% required for bug
\usepackage{onlyamsmath}
% required for tikzpicture
\usepackage{pgfplots}
\usetikzlibrary{calc}
% changes error
\usepackage{siunitx}

\begin{document}

\begin{tikzpicture}
\begin{axis}[name=plot1]
\end{axis}

\begin{axis}[name=plot2,at={($(plot1.east)+(0cm,0)$)},anchor=west]
\end{axis}
\end{tikzpicture}

\end{document}


after it reports this first error (actually the first error is something else but that is only because I reduced it to a minimal example)

! Undefined control sequence.
\next ->\@nil


Can somebody track the origin and or tell me a workaround?

-

## marked as duplicate by egreg, Thorsten, zeroth, Marco Daniel, Andrew SwannFeb 23 '13 at 13:13

You are missing a trailing ] in the first empty axis environment. But it seems that onlyamsmath is having an issue with $(plot1.east)+(0cm,0cm)$. And you also need \usetikzlibrary{calc} to do coordinate calculations. – Peter Grill Feb 22 '13 at 23:28
Perhaps you mean to put egend style={at={($(plot1.east)+(0cm,0)$)}} or something similar to your axis option. – hpesoj626 Feb 22 '13 at 23:29
My bad. I meant to type legend style. – hpesoj626 Feb 23 '13 at 0:08
@PeterGrill I corrected the missing ], but that was not the actual error. \usetikzlibrary{calc} is not needed for this error. One could add it, but that does not solve the problem. – Matthias Pospiech Feb 23 '13 at 8:05
@hpesoj626: This has nothing to do with legends. I align the axis next to each other. I only removed the whole plotting code because it is not relevant for the error. – Matthias Pospiech Feb 23 '13 at 8:06

This bug is an incompatibility between the TikZ calc library and onlyamsmath.

It is caused by the fact that onlyamsmath maliciously changes the meaning of $ so that TikZ fails to parse the expression. More precisely, onlyamsmath changes the catcode of $ to active (code 13) and TikZ's calc library expects a standard math-mode dollar (code 3). I suggest you file a bug report for the author of onlyamsmath: in my humble opinion, changes to standard catcodes almost surely break compatibility with some other package.

I added a sanity check with a useful error message to TikZ in the CVS version such that it detects and reports the incompatibility problem.

Note that the problem is entirely unrelated to pgfplots:

\documentclass{scrbook}

% required for bug
\usepackage{onlyamsmath}
% required for tikzpicture
\usepackage{tikz}
\usetikzlibrary{calc}
% changes error
\usepackage{siunitx}

\begin{document}

\message{Catcode is \the\catcode\$^^J}% %\catcode\$=3
\begin{tikzpicture}

\node (plot1) at (0,0) {};

\node [at={({$({plot1.east})+(0cm,0)$})},anchor=west]
\end{axis}
\end{tikzpicture}

\end{document}

-
Could you change the definition of the catcode and restore it afterwards? – Matthias Pospiech Feb 23 '13 at 10:48
@MatthiasPospiech that's error prone: it would work in some cases, but not in all (e.g. if the tikzpicture has been defined in some macro). And there is nothing that TikZ can do about it. – Christian Feuersänger Feb 23 '13 at 11:07
The latest CVS version of TikZ/PGF (2013/02/23) detects this situation. The log message says: Added sanity check for the catcode of $ to avoid incompatibilities with onlyamsmath package. – Paul Gaborit Mar 1 '13 at 7:36 The problem arises due to two factors. First, onlyamsmath makes $ active with definition

> $=macro: ->\ifx \protect \@typeset@protect \expandafter \futurelet \expandafter \next \e xpandafter \checkdsp \else \expandafter$\fi .


Secondly, there is an \edef hidden in the start of the axis:

\tikz@scan@no@calculator #1(#2)->\edef \tikz@temp {(#2)}\expandafter \tikz@@sca
n@@no@calculator \expandafter #1\tikz@temp
#1<-\pgfplots@set@at
#2<-\$(plot1.east


What therefore happens is that rather than do the \futurelet, the \edef tries to expand \next. The exact meaning depends on what it was last used for (hence the change of error if siunitx is loaded), but the problem is the same.

I'm not sure there is an obvious fix, as there are further assumptions about the behaviour of the argument of at within the pgfplots code.

-
Well, that was double-analysis :) Note that the fact that TikZ's parsing ended up in \tikz@scan@no@calculator is already a follow-up problem because of the wrong \catcode. – Christian Feuersänger Feb 23 '13 at 10:16