# Problem using coordinate returned by macro for drawing line

Why does this MNWE (Minimal Non-Working Example) fail?

\documentclass{article}
\usepackage{tikz}
\begin{document}
\newcommand\mypoint{(1pt,0pt)}
\begin{tikzpicture}
\node [draw,circle] at \mypoint {};
\draw (0,0) to \mypoint;
\end{tikzpicture}
\end{document}


Clearly \mypoint defines a perfectly good coordinate, since the node creation is executed perfectly well, as can be verified by commenting out the \draw command. But an error is obtained when using it to draw a line. What's going on? How can I fix it?

This dumb MNWE is boiled down from a more realistic scenario: the key thing is that I need to be able to draw a line to a point returned by a macro.

-
Related question: Using a macro for the coordinate in \coordinate –  Martin Scharrer Nov 6 '11 at 22:58
You really should use bigger lengths in your MWEs! 1pt is just not enough to see an effect with the human eye at reasonable zoom. –  Andrew Stacey Nov 7 '11 at 9:03
Incidentally, Martin's solution in the linked question also works here: move the parentheses outside the definition of the coordinate so that \mypoint becomes 1pt,0pt and you use \draw (0,0) to (\mypoint);. –  Andrew Stacey Nov 7 '11 at 9:05
add comment

## 1 Answer

The difference is that \node is expanding the next token before it looks at it, which makes \mypoint turn into (1pt,0pt). However, the to in \draw awaits a ( ) directly, otherwise an error is caused by the TeX compiler. That how it got programmed by the TikZ authors.

You have to know that macros can have a parameter text, i.e. certain text can be specified between the arguments. This feature is not accessible through the high level commands of LaTeX like \newcommand. The lower level TeX macro \def (or similar) must be used. You can define a macro like \def\mymacro(#1,#2){ .. } which then awaits a ( direct after it, takes everything until the next , as first argument and then everything between it and a ) as second argument. If any of these characters are missing a TeX compile error is raised. Now, these characters must follow directly and be not part of a macro (because this hides them) or inside { } (because they must be closed first before the text can be matched).

This feature is used heavily in TikZ to program the syntax. Because \node can await several thing in arbitrary order it expands anything first to easy things. However, \draw (x,y) to only awaits a (x,y) afterwards and therefore the underlying macro for to is probably defined like the \mymacro above. Having it expand the next token first would make it more complicated and I guess this was the reason why it isn't included. Or the programmers simply didn't thought about this case.

I suggest you use a \coordinate in your example instead. This avoids this issue.

\documentclass{article}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
\coordinate (mypoint) at (1pt,0pt);
\node [draw,circle] at (mypoint) {};
\draw (0,0) to (mypoint);
\end{tikzpicture}
\end{document}

-
Thanks Martin! Very useful and clear. –  Jamie Vicary Nov 6 '11 at 23:01
Almost, but not quite. TikZ steps along the drawing commands and tests each character that it encounters to decide what to do next. At certain times, it can only handle certain characters because it has different decision trees. So after reading to, the parser is in a restricted part of the tree. The point is that to paths are extremely flexible and the target coordinate is passed as is to the to processor, so it does not allow expansion to be sure that it gets the coordinate as the user specified it. –  Andrew Stacey Nov 7 '11 at 9:01
add comment