Kann ich „auch einen Pfad durchsuchen“, der „auch einen anderen Pfad durchsuchen“ kann?

Kann ich „auch einen Pfad durchsuchen“, der „auch einen anderen Pfad durchsuchen“ kann?

(Dies ist inspiriert vonProblem zwischen Schlüsseln, Pfaden mit zwei Makros und pgfkeys)

Der folgende Code

\documentclass[tikz]{standalone}
\begin{document}
    \pgfkeys{
        %/foo/.search also={/bar,/tikz},
        %/foo/.search also={/bar},
        /bar/.search also={/tikz}
    }
    \tikz\draw[/foo/.cd,fill=red]circle(1);
\end{document}

erzeugt Fehler

Paket pgfkeys-Fehler: Ich kenne den Schlüssel „ /foo/fill“, an den Sie „red“ übergeben haben, nicht und werde ihn ignorieren. Vielleicht haben Sie ihn falsch geschrieben.

Das ist nicht verwunderlich, da darunter nichts steht /foo.



Der folgende Code

\documentclass[tikz]{standalone}
\begin{document}
    \pgfkeys{
        /foo/.search also={/bar,/tikz},
        %/foo/.search also={/bar},
        /bar/.search also={/tikz}
    }
    \tikz\draw[/foo/.cd,fill=red]circle(1);
\end{document}

produziert ein Bild erfolgreich

Dies ist auch nicht überraschend, da beim Versuch, unter und /foozu suchen , festgestellt wird, dass definiert ist.fill/bar/tikz/tikz/fill



Der folgende Code

\documentclass[tikz]{standalone}
\begin{document}
    \pgfkeys{
        %/foo/.search also={/bar,/tikz},
        /foo/.search also={/bar},
        /bar/.search also={/tikz}
    }
    \tikz\draw[/foo/.cd,fill=red]circle(1);
\end{document}

erzeugt überraschenderweise keinen Fehler, sondern ein naives Bild.

Es scheint, als ob /foodie /barSuche fillunter /tikzerfolgreich war (also kein Fehler). Aber aus irgendeinem Grund konnte der Stil nicht angewendet werden.



Warum passiert das? Kann ich irgendwie eines davon bewirken:

  • einen Fehler melden; oder
  • den Stil erfolgreich anwenden; oder noch besser
  • den Stil erfolgreich anwenden und eine Warnung auslösen?

Antwort1

Wenn ich das richtig sehe, wird die Prüfung \ifpgfkeysaddeddefaultpath, die zu Beginn des .unknownvon eingerichteten Codes ausgeführt wird, .search alsoauf „false“ gesetzt, wenn /foo/.unknownVersuche

\pgfqkeys{/bar}{fill=red}

was dazu führt, dass sie /bar/.unknownnichts anderes versuchen.

(Das ist im Grunde der Unterschied zwischen /bar/.cd, fill=redund , /bar/fill=redwobei Letzteres als richtig angenommen wird und trotz einer .search alsoAlternative absichtlich einen Fehler auslöst.)

Ich habe nicht die Geduld, nachzuschauen, warum das so ist und wo es passiert und ob es sich überhaupt um einen Fehler handelt oder ob es beabsichtigt ist, aber es scheint einfacher, einen benutzerdefinierten .unknownHandler einzurichten …

Es hängt einfach davon ab, wie Sie manche Dinge handhaben möchten.


Da /tikz/.unknowndie Prüfung nicht durchführt, \ifpgfkeysaddeddefaultpathwird nicht zwischen /tikz/.cd, <key>=<value>und unterschieden /tikz/<key>=<value>. (Intern wird statt .cdoft das schnellere \pgfqkeys{/tikz}{<key>=<value>}verwendet, aber das ist im Grunde dasselbe.)

Manchmal ist jedoch <key>ein Stil und dann hängt es davon ab, in welchem ​​Pfad wir sie ausführen.

\pgfkeys{/abc/.cd, /tikz/thick}

führt zu einem Fehler bezüglich eines unbekannten Schlüssels, /abc/line widthda wir uns noch im /abcPfad befinden (es sei denn /abc/line widthnatürlich, es ist definiert, dann wird das verwendet).

Dies führt mich zu einem .unknownHandler, der sehr nah an derBeispiel aus dem Handbuch.

Leider /tikz/.unknownwird nicht festgelegt \pgfkeyssuccesstrue, wann eine Farbe, eine Pfeilspezifikation oder der Name einer Form gefunden wird. Dadurch lässt sich nur schwer feststellen, ob ein /tikz/<key>tatsächlich erfolgreich war. Dies bedeutet, dass der Betreuer /fookeine richtige Fehlermeldung anzeigen kann, ohne es neu zu definieren /tikz/.unknownoder selbst die gleiche Geschichte zu erzählen.

Code

\documentclass[tikz]{standalone}
\begin{document}
\pgfkeys{
  /bar/.search also=/tikz, % this can stay, I guess
  /foo/.unknown/.code=
    \ifpgfkeysaddeddefaultpath
      \let\unknownname\pgfkeyscurrentname
      \pgfkeysalso{
        /bar/\unknownname/.try={#1}, % only try /tikz if /bar failed
        /tikz/\unknownname/.lastretry={#1}}%
        % Ugh! /tikz/.unknown doesn't set \pgfkeyssuccesstrue
        % after it handles a color, an arrow specification or a shape's name
        % then this will be annoying:
        \unless\ifpgfkeyssuccess
          \errmessage{Well, I couldn't find /foo/\unknownname={#1},
                      /bar/\unknownname={#1} and /tikz/\unknownname={#1}.
                      I don't know what you want from me.}%
        \fi
    \else % someone tried to do /foo/<unknown key>, let's fail:
      \errmessage{myPackage: /foo/\pgfkeyscurrentname\space is an unknown key.}%
    \fi
}
\tikz[radius=1]{
  \draw[/bar/.cd, fill=red] circle[];
  \draw[/bar/fill=red]      (right:1) circle[];% will always fail
  \draw[/foo/.cd, fill=red] (right:2) circle[];
  \draw[/foo/fill=red]      (right:3) circle[];% will always fail
}

\tikz{
  \draw[/bar/.cd, inner xsep=0+0] node {\pgfkeysvalueof{/pgf/inner xsep}};
  \draw[/foo/.cd, ->]     (right:1) -- +(right:.5); % Ugh!
  \draw[/foo/.cd, red!50] (right:2) -- +(right:.5); % Ugh!
  \draw[/foo/.cd, circle] (right:3.5) node[draw]{}; % Ugh!
  \draw[/foo/.cd, thick]  (right:4) -- +(right:.5);% finds /tikz/thick but then
                                                   % has to try /foo/line width
                                                   % and then /bar/line width and
                                                   % then finally /tikz/line width
}
\pgfkeys{/tikz/.cd, abc}% → unknown /tikz/abc
\pgfkeys{/bar/.cd, abc} % → unknown /tikz/abc
\pgfkeys{/foo/.cd, abc} % → unknown /foo/abc, /bar/abc, /tikz/abc
\end{document}

Ausgabe

Bildbeschreibung hier eingeben

Bildbeschreibung hier eingeben

verwandte Informationen