From the pgfkeys.code.tex
file:
% This is useful:
\def\pgfkeys@ifcsname#1\endcsname#2\else#3\fi{\expandafter\ifx\csname#1\endcsnam
e\relax#3\else#2\fi}%
\ifx\eTeXrevision\undefined%
\else%
\expandafter\let\expandafter\pgfkeys@ifcsname\csname ifcsname\endcsname%
\fi
The command \pgfkeys@ifcsname
is used internally to check if a key exists. If etex
is present, it is simply \ifcsname
. If not, then it is a fallback which (in the cases where it is used) is deemed good enough.
However, it doesn't work well with nested conditionals. It is sometimes used via another command:
\long\def\pgfkeysifdefined#1#2#3{\pgfkeys@ifcsname pgfk@#1\endcsname#2\else#3\fi}
The problem here is that if #2
or #3
contains another conditional then because \pgfkeys@ifcsname
uses macro parameter matching instead of conditional matching, then an \else
or \fi
inside #2
or #3
can get matched instead of the given ones. Adding braces wouldn't work since that would add an extra set of braces.
Now, I intend reporting this on the PGF bug list, but thought I'd have a go at coming up with a replacement first.
I thought of:
\def\pgfkeys@ifcsname#1\endcsname{\ifx\csname#1\endcsname\relax\expandafter\iffalse\else\expandafter\iftrue\fi}
So my question: does this suffer from any more problems that the original didn't already suffer from?
(So the fact that \csname undefinedcommand\endcsname
makes \undefinedcommand
into \relax
is not an objection to the new definition as it already exists in the original one.)
\expandafter
\ifx\csname#1
comparescsname
and the first token of#1
, with the expandafter it suffers from same syntax problem as original. Really they ought to use\if\@undefined{#1}
so the\if
token is exposed (egerg had an answer on this the other day, I'll look it up)