4

For me (using pdflatex: pdfTeX 3.14159265-2.6-1.40.17 (TeX Live 2016)) the following code compiles fine, but if I uncomment the second loop it fails to compile with a "Giving up on this path..." error message. Am I doing something stupid?

\documentclass{article}

\usepackage{tikz}

\begin{document}
    \begin{tikzpicture}
        \path coordinate (P) at (7,10);
    \end{tikzpicture}

    \begin{tikzpicture}
        \foreach \position [count=\posi] in {(0,0), (3,0), (4,1), (5,2), (4,4), (2,5), (1,3)} 
            \path \position coordinate (P\posi);
    \end{tikzpicture}

    % \begin{tikzpicture}
    %     \foreach \position [count=\posi] in {(0,0), (3,0), (4,1), (5,2), (4,4), (2,5), (1,3)}
    %         \path coordinate (P\posi) at \position;
    % \end{tikzpicture}
\end{document}

2 Answers2

2

No you do not do anything stupid. Similar expansion issues have been reported here. Anyway, you have already found yourself a nice way out. Alternatively you could go along the lines in one of the answers to that question.

OLD ANSWER: Thanks to @Zarko: Simplest solution: update your TeX distribution.

If you do not want to do that (or cannot do that), you need to put the coordinates into braces since they contain a comma, which is also the separator in the \foreach list. If you do not put the braces, older versions of pgffor will interpret the first entry as (0, and this obviously leads to an error. The same issue will arise in newer versions in which you have more complicated items in the list. Generally, I do not think that the braces hurt.

\documentclass{article}

\usepackage{tikz}

\begin{document}
    \begin{center}
        \begin{tikzpicture}
            \foreach \position [count=\posi] in {{(0,0)}, {(3,0)}, 
            {(4,1)}, {(5,2)}, {(4,4)}, {(2,5)}, {(1,3)}} 
            {
                \path \position coordinate (P\posi);
                % \coordinate (P\posi) at \position;
            }
        \end{tikzpicture}
    \end{center}
\end{document}
  • @TikzerWoods I am talking about \path coordinate (P) at (7,10); at the very beginning of the code. –  Jun 19 '18 at 19:49
  • @TikzerWoods Yes, but this is what the OP is doing in his first loop. Have a look here. –  Jun 19 '18 at 19:57
1

The problem is that after at you have to use ( as noted in the manual

\path ... coordinate[<options>](<name>)at(<coordinate>) ...;

This is why \path coordinate (P\posi) at \position; is not working, but \path \position coordinate (P\posi); is ok.

EDIT: As mentioned @marmot in his comment, the problem is that \position is not expanded when tikz is parsing for ( after the at.

If you really want to use at, I don't know why somebody would, you ca say ... at ([shift=\position]0,0) ... that force the expansion of \position, but in this case if your \position was a named coordinate, it will stop to be.

Kpym
  • 23,002
  • I guess you'd need to add that there is an expansion issue. Otherwise it is rather confusing because the coordinates start with (. The issue is that they are not expanded at the time TikZ tries to parse the path. –  Jun 19 '18 at 22:46