# Can pgfkeys deal with active comma?

When I tried to compile

\begingroup
\def\iden#1{#1}
\catcode\,=13
\catcode\==13
\iden{\endgroup
\pgfkeys{/my family/.is family}
\pgfkeys{/my family/my keys/.cd,
keya/.code=\def\mywidth{##1},
keyb/.code=\def\mydefault{##1}%
}%
}


I got the error

{\edef}
\pgfkeyscurrentkey ->/my family/my keys/.cd, keya/.code
{undefined}
! Undefined control sequence.
\pgfkeyscurrentkey ->/my family/my keys/.cd,


Please how can I get over this? pgfkeys' Chief Executive (to use Knuth's term) doesn't seem to be able to inherently handle active parsers.

-
It can't deal also with active =. Try with \usepackage[turkish]{babel}. –  egreg Apr 9 '12 at 22:54
@egreg: You're right. Active = is even a bigger problem; see latex-project.org/cgi-bin/ltxbugs2html?pr=babel/3523. Also, \pgfkeys{/my family/my keys/keya={x}} strips the braces around x. Furthermore, I find that its leading and trailing space trimmer (\pgfkeys@spdef) is an exact replica of keyval package's \KV@@sp@def, thereby inheriting the known deficiencies of \KV@@sp@def. In order to be usable for general purposes, pgfkeys needs to be more robust. Or there supplements (ie, add-ons) that attend to the need for more resilience? –  Ahmed Musa Apr 10 '12 at 2:12

## Original Answer

In general, as long as delimited argument matching is used to parse the value list, redefining catcodes of list syntax characters will be a problem (same for LaTeX lists).

One could redefine \pgfkeys@@set to re-catcode , and = like this:

\makeatletter
\long\def\pgfkeys@@set#1#2{%
\let\pgfkeysdefaultpath\pgfkeys@root%
{\catcode\,=12\catcode\==12
\scantokens{\def\mytmp{#2}}%
\expandafter
}%
\expandafter\pgfkeys@parse\mytmp,\pgfkeys@mainstop%
\def\pgfkeysdefaultpath{#1}}
\makeatother


I'm not getting much of a test result as your MWE doesn't produce any output, but at least I'm getting no errors ;-)

Don't know whether this was the kind of general robust solution you're looking for though...

## Edit

Please see the comments below on why the above is not a good idea. \scantokens will de-activate all instances of , and = in its argument, also in the values of keys where they need to be active to fulfill the purpose they were originally made active for.

Following the comment of Joseph Wright below, here is a "solution" referring to the kvsetkeys package (Which was, obviously, an enormous tedium to make. Kudos to Heiko for this achievement!):

\usepackage{kvsetkeys}
\usepackage{tikz}

\makeatletter
\long\def\pgfkeys@@set#1#2{%
\let\pgfkeysdefaultpath\pgfkeys@root%
\kv@normalize{#2}%
\expandafter\pgfkeys@parse\kv@list,\pgfkeys@mainstop%
\def\pgfkeysdefaultpath{#1}}
\makeatother


Again, I'm getting no errors :-)

I'd be interested to hear what the drawbacks of this approach are.

-
I would avoid \scantokens in general: you don't know what other changes may apply. I'd prefer the approach in kvsetkeys where a search-and-replace alters only the catcode of 'delimiting' = and ,, leaving for example tokens 'hidden' within braces unchanged. (We use the same approach in l3keys for LaTeX3.) –  Joseph Wright Apr 10 '12 at 16:46
@JosephWright Thanks for the comment. I'll try to update my answer maybe this evening. –  Stephan Lehmke Apr 10 '12 at 16:52
@AhmedMusa It seems you know much more about these matters than I do. Should I delete my answer? –  Stephan Lehmke Apr 10 '12 at 18:08
As Joseph has noted, \scantokens is not recommended here since, even if the token list in question was scannable, rescanning will introduce unintended changes to the token list. If, for instance, the user wanted genuinely active = in the token list (which he might do, for example, by hiding such active = in brace groups), rescanning will infringe that requirement and some other things. Joseph suggests list normalization by Heiko’s method. That is what ltxkeys too adopted. –  Ahmed Musa Apr 10 '12 at 18:10
There is also the relatively more expensive scheme of selective sanitization (SS) by Uwe Kern, as used in xkeyval package. A limitation of SS concerning \bgroup token was addressed by ltxtools-base package. –  Ahmed Musa Apr 10 '12 at 18:11

EDIT (2012/04/21)

I needed to correct and extend some lines in the package, but the site's limit of 30000 characters was exceeded. So I have moved the package to CTAN as pgfkeyx.

Examples

\documentclass{article}
\usepackage{pgfkeys}
\usepackage{pgfkeyx}
\makeatletter

\begingroup
\def\iden#1{#1}
\catcode\/=13
\catcode\,=13
\catcode\==13
\iden{\endgroup
\pgfkeys{%
% The spaces here are just examples of how they are removed by
% normalization:
/ my family / .is family,
/my family/my keys/.cd,
keya / .code = \def\keyavalue{#1},
keya/.default = {keya-default},
keyb / .code = \def\myvalueb{#1},
keyb /.default=keyb-default,
.normal code=\def\x#1{#1},
keyc/.code=\pgfqkeysalso\pgfkeyscurrentpath{#1},
keyc/.value required,
keyd/.is if with 2 callbacks =
{true}{\def\x##1{##1-True-#1}}{\def\x##1{##1-False-#1}},
}%
}

\pgfkeys{%
/my family/my keys/.cd,
keya={x},
keyb=aa,
keyc = {keya=aa, keyb=bb},
}

\pgfkeys{%
/my family/my keys/.cd,
keya/.restore default,
.restore key defaults={keya,keyb}
}

\makeatother

\begin{document}
\pgfkeys{%
/my family/my keys/keyd=true,
}
\ifkeyd
keyd' is true.
\fi
%\show\x
\end{document}

-
I'm really interested by your solution :) –  cjorssen Apr 11 '12 at 11:23
Apart from the question what the tikz team would prefer, I don't think anything is keeping you from making a package which patches pgfkeys and which could then be recommended here to users getting issues with active = or ,. –  Stephan Lehmke Apr 13 '12 at 20:37
@StephanLehmke: Here you go. I have edited my answer to include a rather incomplete patch. See comments within the code. I have included a provision for resetting keys to their default values, something Ben User wanted some weeks ago. –  Ahmed Musa Apr 13 '12 at 22:25
@AhmedMusa Thanks for this patch. I added a link in the bug tracker to your answer (this has been an open bug since 2008!). We need to remove all etex features to include it in pgf code since it is the policy of pgf/tikz for now (this might change in the future). –  cjorssen Apr 14 '12 at 10:43
@cjorssen: OK. Before I used eTeX features for the patch I confirmed from Joseph Wright that eTeX is now available on more than 99% of all TeX distributions. The earlier that policy changes the better for contributors to tikz. Life without eTeX is awkward. –  Ahmed Musa Apr 14 '12 at 18:04