New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
\foreach behavior inside a \draw #1303
Comments
The issue appears to be that the (Once I've updated my local version of PGF then I can create a pull request for this, but I've only tested it with the broken code so haven't verified that it doesn't break anything else.) |
In the code: ``` \draw (A) foreach \nd in {B,C} { -- (\nd) }; ``` then the line to `C` is drawn from `A`, not `B`. This is because the foreach loop does not update the macro that remembers that the last coordinate was a node. This fixes that issue. See pgf-tikz#1303
Thanks again for your reply. \tikz
\draw (0,0)
foreach \x in {1,...,3} { -- (\x,1) -- (\x,0) }; Which works as one would expect, I mean, connecting (0,0) -- (1,1) -- (1,0) -- (2,1) -- (2,0) -- (3,1) -- (3,). |
Similar: #1047, in which |
I've refactored my fix to make it more extendible, and included |
In the code: ``` \draw (A) foreach \nd in {B,C} { -- (\nd) }; ``` then the line to `C` is drawn from `A`, not `B`. This is because the foreach loop does not update the macro that remembers that the last coordinate was a node. This fixes that issue. See pgf-tikz#1303 Signed-off-by: Andrew Stacey <loopspace@mathforge.org>
This commit adds more information to what TikZ remembers between foreach iterations, and does so in a way that makes it easier to add other macros and dimensions to the list of things it remembers, both at the code level and via keys. Fixes pgf-tikz#356, pgf-tikz#1047, pgf-tikz#1303, pgf-tikz#1313 Signed-off-by: Andrew Stacey <loopspace@mathforge.org>
Brief outline of the bug
Hi,
I don't know if it qualifies as a bug, or a misunderstanding of mine about how a
foreach
should work, when used inside apath
.From my understanding, section 88 of the manual (pages 1001+), the foreach should just, mainly, expands the code inside the braces (if there is one, replacing the variables of the foreach).
In the example below, my understanding was that the 3 cases (commented out) should be equivalent. producing a line from (X) to node (nA) node (nB) and finally coordinate (X).
case (1), the simplest, does just that, connecting the arcs (at node nA and node nB) as expected.
case (2), 'does the job', by means of three \draw commands
\draw (X) -- (nA) ; \draw (nA) -- (nB); \draw (nB) -- (X)
case (3) was the surprise for me, I expected it to be equivalent too (well, to be equal to case (1)) .. but I got a continuous line from (X) to (Y) ignoring the nodes (arcs) dimensions.
Is that the expected behavior? what am I missing on it? or is it a foreach miss behavior ?
For a better context: I'm using this construct with coordinates obtained from
\draw[name intersections={of=...
(intersections library). So I'm forced to use foreach statements to connect the many 'intersection' coordinates, in which I place an arc node in each intersection.
In my use case what I have implemented, for now, is a workaround based on case (2), better said, from the intersection coordinate/nodes list I generate a clist of node-pairs then I execute a final foreach with said list.
(that's just to have an idea what I ended doing,
#3
would beX
,#4
would beY
,#2T
is the macro name with the number of intersections.. then#2-\x
are the intersection node names. It works, just fine, but it would be nicer not to have to use such a construct to just connect the nodes, and be able, for instance, to have something likeMinimal working example (MWE)
The text was updated successfully, but these errors were encountered: