Please is there a way to avoid inadvertent cyclic linking of keys in \pgfkeys? A minimal example follows. Here I have keyb<->keya, which took its toll on TeX's capacity.
\documentclass{article}
\usepackage{pgfkeys}
\pgfkeys{/handlers/.normal code/.code={#1}}
\pgfkeys{%
/my family/.is family,
/my family/.cd,
keya/.code = \def\keyavalue{#1}\pgfkeysalso{keyb=keybvalue2},
keya/.default = {keyadefault},
keyb/.style = {keya={#1}},
%.normal code =\begingroup\loggingall,
keyb = keybvalue1,
%.normal code =\endgroup
}
\begin{document}
xx
\end{document}
The above depicts the source of my original problem. Here is a more obvious but nastier one:
\pgfkeys{%
/my family/.is family,
/my family/.cd,
keya/.code = \pgfkeysalso{keya=keyavalue2},
keya = keyavalue1
}
I believe there is a way to create a native safety mechanism in this case. It will be sufficient to require that no key links back to itself. That is what xkeyval package does. I know that TeX, like some other languages, leaves much to be desired in this case. Have fun with
\def\y{\x}
\def\x{\y}\x
An Oberdiek test for any key-setting macro is that it must be infinitely reentrant. This is purposeful but it does lead to the possibility of bombing out, as indicated here.
In the ltxkeys package, a maximum of nesting level or depth of \ltxkeys@setkeys is used to guard against infinite reentry. Also, in that package, style keys can't be back-linked.
\XKV@r@placepointers. I thought pgfkeys had a similar scheme. Because even for an experienced pgfkeys coder, it is possible to link keys cyclically. In a serious project it can be tasking to implement manual assertion for one and every key that is linked to another. – Ahmed Musa Jul 2 '12 at 15:44pgfkeyscode I can say that it does no such thing. To do it yourself you do not need to flag every key, just the ones that are the "start" of something you don't want to be cycled back to. This problem is much easier to solve with mindful coding than by writing a safety net. – Ryan Reich Jul 2 '12 at 18:50