This might seem a trivial question, but not for someone wanting to understand pgfkeys very well. In the following definition from pgfkeys package, why can't the \edef be replaced by \def? I have asked a pgfkeys master this question before but apparently he didn't get the question correctly, since I mixed it with other issues.
\pgfkeys{%
/handlers/.is family/.code=
\pgfkeys{\pgfkeyscurrentpath/.ecode=
\edef\noexpand\pgfkeysdefaultpath{\pgfkeyscurrentpath/}
}
}
The following gives me the same result even as \edef is replaced by \def. Am I right?
\pgfkeys{%
/handlers/.is family/.code=
\pgfkeys{\pgfkeyscurrentpath/.ecode=
\def\noexpand\pgfkeysdefaultpath{\pgfkeyscurrentpath/}
}
}
\def\firstlayerfam{/fam/subfam}
\def\secondlayerfam{\firstlayerfam}
\def\family{\secondlayerfam}
\pgfkeys{
\family/.is family,
\family % This changes the path even without '.cd'. OK!
}
EDIT
The reason I see is in the following
\long\def\pgfkeys@unpack#1=#2=#3\pgfkeys@stop{%
\pgfkeys@spdef\pgfkeyscurrentkey{#1}%
% The following \edef is crucial. In fact, it should come before the last line
% (ie, before calling the Carlisle despacer \pgfkeys@spdef). Because if #1 is
% a macro, the content may be the one that carries spurious leading and
% trailing spaces. Without expansion, \pgfkeys@add@path@as@needed may even add
% default path when it isn't needed. See below.
\edef\pgfkeyscurrentkey{\pgfkeyscurrentkey}%
\ifx\pgfkeyscurrentkey\pgfkeys@empty%
% Skip
\else
\pgfkeys@add@path@as@needed
\pgfkeys@spdef\pgfkeyscurrentvalue{#2}%
\ifx\pgfkeyscurrentvalue\pgfkeysnovalue@text% Hmm... no value
\pgfkeysifdefined{\pgfkeyscurrentkey/.@def}%
{\pgfkeysgetvalue{\pgfkeyscurrentkey/.@def}{\pgfkeyscurrentvalue}}%
{}% no default, so leave it
\fi%
\ifx\pgfkeyscurrentvalue\pgfkeysvaluerequired%
\pgfkeysvalueof{/errors/value required/.@cmd}%
\pgfkeyscurrentkey\pgfkeyscurrentvalue\pgfeov%
\else%
\pgfkeys@case@one%
\fi%
\fi
}
Trace log:
{changing \pgfkeyscurrentkey=macro:->\family /.is family}
{into \pgfkeyscurrentkey=macro:->//fam/subfam/.is family}
\edefhere as there is.ecode. I suspect this is a 'historical oversight': if you readpgfkeysyou find a few of these. (When I wrotel3keys, basing it onpgfkeys, I had a lot of 'fun' as a result.) – Joseph Wright♦ Jun 15 '12 at 19:31