Path styles like short and R modify coordinate even if +(x,y) is used

[septatrix]

When drawing a circuit and using path styles provided by circuitikz like short or R the current coordinates are unexpectedly modified. This is not a problem when absolute coordinates are used or relative coordinates using ++ notation. If one however uses temporary relative coordinates using + (which revert the coordinates to the previous ones after drawing the path) this leads to problems.

MWE

\documentclass{article}
\usepackage{circuitikz}

\begin{document}

\begin{circuitikz}
  \draw
    (0,0)
    {[] to[short] +(2,0)}
    +(0,0) -- ++(0,-1)
  ;
\end{circuitikz}

\end{document}

Expected output from MWE

Actual output from MWE

The expected output can be archived when adding current point is local in the empty brackets before the to[short] or removing the short style. However the former solution can not always be used and is cumbersome while the latter obviously becomes impossible if one wants to use styles like a resistor...
I am fairly certain that tikz can handle this as decorations seem to work similar to the path styles and correctly handle these temporary relative coordinates.

[Rmano]

This is effectively a limitation of the to path handler of circuitikz. I will mark this as a bug, but I am not sure it is possible to solve it easily. The to path handler is doing a lot of things (drawing labels, setting anchors for voltages, etc.).
So for now please use named coordinate to remember the initial position. I will at least add a notice about the temporary relative path movements in the manual.
If you want to have a peek, the thing is in tex/pgfcircpath.tex.

[septatrix]

You may also want to mention current point is local which I am currently using to get around this. It eliminates the need for named coordinates or absolute positions: (previous coordinate) {[current point is local] do something which messes up the current coordinate} automatically restored to previous coordinate

[Rmano]

Sorry for the delay (busy thing here). I came to the conclusion that this is not fixable. If you look at the following MWE, you'll see that circuitikz has the same behavior as non-trivial to path elements in core TikZ:

\documentclass{article}
\usepackage[RPvoltages]{circuitikz}

\begin{document}
\begin{circuitikz}
    \draw[color=red] (0,0) {[] to[R] +(2,0)} +(0,0) -- ++(0,-1);
\end{circuitikz}
\qquad
\begin{circuitikz}
    \draw[color=blue] (0,0) {[] to[out=30, in=120] +(2,0)} +(0,0) -- ++(0,-1);
\end{circuitikz}
\qquad
\begin{circuitikz}
    \draw[color=purple] (0,0) {[] to[] +(2,0)} +(0,0) -- ++(0,-1);
\end{circuitikz}
\end{document}

Notice the blue one --- it uses no circuitikz code at all but it still is forgetting the path position.

[septatrix]

Hm it might be interesting to open an issue in the tikz repo to find out if this is intended or could be circumvented on their side.

[Rmano]

I am not sure it is a bug (although it's a bit unexpected, yes). I do not know how to fix it at circuitikz level, because I do not know if the coordinate in \tikztotarget has been reached by a +() or a ++() coordinate.
Hmmm....

[hmenke]

I currently do not know whether this has any adverse side effects. It seems to me that it probably does because the .. operator used to unconditionally set \tikz@updatecurrenttrue which is quite a strong assumption.

diff --git a/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarytopaths.code.tex b/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarytopaths.code.tex
index 36df6b69e..43e4c8959 100644
--- a/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarytopaths.code.tex
+++ b/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarytopaths.code.tex
@@ -135,6 +135,7 @@
   [every curve to]
   \pgfextra{\iftikz@to@relative\tikz@to@compute@relative\else\tikz@to@compute\fi}
   \tikz@computed@path
+  \pgfextra{\tikz@updatenexttrue}%
   \tikztonodes%
 }
 
@@ -166,6 +167,9 @@
   \def\tikz@first@point{#1}%
   \tikz@scan@one@point\tikz@@@to@compute@distance(\tikz@toto)}
 \def\tikz@@@to@compute@distance#1{%
+  \iftikz@updatecurrent\else
+    \tikz@updatenextfalse
+  \fi
   \def\tikz@second@point{#1}%
   \tikz@to@compute@distance@main%
 }
diff --git a/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex b/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex
index 70f8da088..bc9031dcf 100644
--- a/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex
+++ b/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex
@@ -3262,7 +3262,9 @@
   \else%
     \tikzerror{Dot expected}%
   \fi%
-  \tikz@updatecurrenttrue%
+  \iftikz@updatenext
+    \tikz@updatecurrenttrue%
+  \fi
   \tikz@curveCcheck%
 }%
 \def\tikz@curveCcheck{%
@@ -5221,11 +5223,15 @@
     \tikz@lastxsaved=\pgf@x\relax%
     \tikz@lastysaved=\pgf@y\relax%
   \fi%
-  \tikz@updatecurrenttrue%
+  \iftikz@updatenext
+    \tikz@updatecurrenttrue%
+  \fi
 }%
 
 \newif\iftikz@updatecurrent
 \tikz@updatecurrenttrue
+\newif\iftikz@updatenext
+\tikz@updatenexttrue
 
 
 

[Rmano]

@hmenke Uff, seems dangerous for a newbie like me. I will try to see if applying it and recompiling circuitikz manual will make something explode. Thanks for the effort!

[Rmano]

@septatrix it seems that @hmenke fixed it --- it will be in a future TikZ release, I think.

[Rmano]

Fixed in pgf-tikz/pgf@95d8a97 by @hmenke

Subsequently, I found a problem in circuitikz that I will fix soon in 1.2.7, that will close this issue. Notice that if you upgrade TikZ you must upgrade circuitikz.

[Rmano]

@hmenke @muzimuzhi there is another effect of this change ---I'm not opening a ticket because I am quite sure that the wrong-doing was in circuitikz, but given that @hmenke told me once to report changes anyway, here it is.

This changed the behavior of labels incircuitikz when to is used with relative coordinates (well, it broke them). To summarize, the snippet

\documentclass{article}
\usepackage[RPvoltages]{circuitikz}

\begin{document}
circuitikz: \pgfcircversion

pgf/tikz: \pgfversion

\begin{circuitikz}%[circuitikz/label/align=rotate]
\draw (0,0) to [L,l=$L_{nn}$] +(5,0);
\end{circuitikz}
\end{document}

produces

with a newer TikZ and

with an older one (notice the $L_{nn}$ position).

This is fixed by just avoiding relative moves inside the to-path command: #570 --- I think that this is nevertheless the correct thing to do.

Just adding this comment to possibly help in the future. Thanks!