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.

\pgfkeys{/handlers/.normal code/.code={#1}}
    /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


The above depicts the source of my original problem. Here is a more obvious but nastier one:

    /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


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.

  • Since you're the one writing the keys, you can put anything you like in them -- including a conditional asserting that the key has already been called. – Ryan Reich Jul 2 '12 at 15:02
  • I am a beginner. The xkeyval package has an alert for flagging back-linking of pointers. You can find it in the macro \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:44
  • 3
    What you describe is a general programming issue, of course. Having gone through the pgfkeys code 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

As key setting can involve arbitrary code, the short answer is that there is no way to prevent all possible circular key-setting situations. You can image a first key calling code which executes a macro, which then sets other keys which then refer back to the very first one, etc. As mentioned in comments, this is an entirely general programming issue and not limited to pgfkeys or TeX.

| improve this answer | |
  • I encountered the same problem with \presetkeys command of xkeyval package. If a preset key sets a key in its own family (i.e., if the callback of a preset key calls \setkeys in the current family), then back-linking results. In the skeyval package the problem is solved (actually, the exception is caught) by setting an upper bound for the re-entry depth of \skvsetkeys (another form of \setkeys). If the depth exceeds some number N , then something weird is playing out. – Ahmed Musa Aug 4 '13 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.