Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

Please does anyone know the 'filtering state' referred to in the following code from the pgfkeys-core file?

\def\pgfkeys@install@filter@and@invoke#1{%
  \ifpgfkeysfilteringisactive
    \pgfkeys@error{Sorry, nested calls to key filtering routines are
      not allowed. Reason: It is not possible to properly restore the
      previous filtering state after returning from the nested call}%
  \fi
  \pgfkeysfilteringisactivetrue
  \let\pgfkeys@case@one=\pgfkeys@case@one@filtered
  \let\pgfkeys@try=\pgfkeys@try@filtered
  \let\pgfkeys@keyunknown=\pgfkeys@keyunknown@filtered
  #1%
  \let\pgfkeys@case@one=\pgfkeys@orig@case@one
  \let\pgfkeys@try=\pgfkeys@orig@try
  \let\pgfkeys@keyunknown=\pgfkeys@orig@unknown
  \pgfkeysfilteringisactivefalse
}

Is the 'state' the following functions?

\pgfkeysfilteringisactive % boolean
\pgfkeys@case@one
\pgfkeys@case@one@filtered
\pgfkeys@try
\pgfkeys@try@filtered
\pgfkeys@keyunknown
\pgfkeys@keyunknown@filtered
share|improve this question
add comment

2 Answers

up vote 3 down vote accepted
  1. I believe that I wrote that code. In fact, I wrote the complete key filtering stuff in the first place. So, the answer should probably be "I should have known it at some time".

  2. Your questions sounds like "Why is nested key filtering harmful?" or even "How can I extend key filtering such that it allows for nested calls?". Your questions seems to be an attempt to answer that/these question(s) by means of a third question, right?

  3. I think the reason why nested key filtering calls are forbidden is that key filtering is inherently stateful: key filtering means to call some handler; and pgfkeys does not know anything about that (external!) handler and its state. It could mean to collect filtered keys, for example (a common use case). Would that work correctly with nested calls? Would that reinit the handler? Would it need to do so? Should both root-level and nested handlers be active at the same time? Or only one of them? Why?

  4. Why do you need nested key filtering? I am using key filtering intensively (for pgfplots) and I never even touched that limitation...

In any case, I would suggest to continue the discussion offline as it is mainly about implementational details of PGF. Perhaps I can find you answers, and perhaps the pgf CVS history function will tell you more about that feature even without asking me. You can send an email to me if you want to continue the discussion.

share|improve this answer
    
Thanks. It's helpful that I have found the Wilhelm Richard Wagner of pgfkeys. Discussion continues offline. –  Ahmed Musa Apr 30 '12 at 0:44
add comment

I think the filter state is rather the values of all the macros and stuff describing what's currently going on with filtering, like \pgfkeyscurrentkey, \pgfkeyscurrentvalue and such.

The names you mentioned are just fixed commands which are only switched between "filtered" and "orig" when the filter is activated, they don't represent a state.

From what I can see in the code, some attempts at making save/restore possible have been made, see for instance

% % THIS VERSION IS TOO SLOW. See below.
% \def\pgfkeysevalkeyfilterwith#1{%
%   \edef\pgfkeys@eval@key@filter@subroutine@restorestate{%
%       \noexpand\def\noexpand\pgfkeyscurrentkey{\pgfkeyscurrentkey}%
%       \noexpand\def\noexpand\pgfkeyscurrentkeyRAW{\pgfkeyscurrentkeyRAW}%
%       \noexpand\def\noexpand\pgfkeyscurrentname{\pgfkeyscurrentname}%
%       \noexpand\def\noexpand\pgfkeyscurrentvalue{\pgfkeyscurrentvalue}%
%       \noexpand\pgfkeys@pathtoks={\pgfkeyscurrentpath}%
%   }%
%   \pgfkeysinterruptkeyfilter
%   \let\pgfkeys@case@one=\pgfkeys@eval@key@filter@subroutine@case@one
%   \pgfkeysalso{#1}%
%   \endpgfkeysinterruptkeyfilter% this here also restored \pgfkeys@case@one.
%   \pgfkeys@eval@key@filter@subroutine@restorestate
% }%
%-------------------------------------------------- 

But it seems that has been deemed infeasible without using TeX grouping. Well at least that is what I read in the code.

share|improve this answer
    
Thanks. The snippet you gave was abandoned by the author and it doesn't build a stack. It won't work in a nest. If simple (no-filter) key processing was mixed with filtered calls, then the 'fixed macros' will have to be stacked too. I hope one of the authors of pgfkeys will come around here. I want to nest key processing (within and across simple and filtered) irrespective of cost. –  Ahmed Musa Apr 29 '12 at 21:26
    
@AhmedMusa Yes I had guessed it was just a stub of the neccessary implementation, but at least it shows some of the relevant state variables. –  Stephan Lehmke Apr 30 '12 at 2:46
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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