User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812
            Thunderbird/6.0
MIME-Version: 1.0
References: <C58398B6-8915-458C-AF38-F3C82F9342B2@gmail.com>           
            <4E4FF538.7070601@morningstar2.co.uk>
            <9788A2B7-3E8F-4D2C-A52E-10999BCB59FA@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4E516DF2.4040002@morningstar2.co.uk>
Date:         Sun, 21 Aug 2011 21:43:30 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: couple of l3keys notes
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <9788A2B7-3E8F-4D2C-A52E-10999BCB59FA@gmail.com>
Precedence: list
Status: R

On 21/08/2011 08:41, Will Robertson wrote:
>>> 3.
>>>
>>> I think it's generally useful to be able to filter lists of keys into their various modules.
>>
>> When I was writing l3keys, this idea was not really available in
>> pgfkeys. However, there is now a  filter add-on to pgfkeys which does
>> exactly what you describe. (See the Tikz manual, section 'Key
>> Filtering'.) I find some of the current pgfkeys approach a bit hard to
>> follow, so if we do want to go this way will probably come up with a
>> proposal of my own. I'll come back on this once I've given it some more
>> thought, and hopefully will have an interface idea.
> 
> Sure; thanks. I don't think this needs to be too complex; at a bare minimum the xkeyval approach of returning the unset keys works for most cases.

Okay, there are several approaches we might consider in this area. There
are also questions about what is needed. For example, is it important to
_know_ the two independent lists of keys, or just to pass unknown keys
from one root to another? I guess I favour the later approach, provided
it can do the required work here.

With the current implementation, you can achieve something useful with
an approach such as

  \keys_define:nn { foo }
    {
      unknown .code:n =
        {
          \use:x
            {
              \keys_set:nn { bar }
                {
                  \exp_not:o \l_keys_key_tl
                    \tl_if_blank:nF {#1} { = \exp_not:n {#1} }
                }
            }
        }
    }

which will pass keys not know to 'foo' on to the 'bar' family. The
obvious issues with this are (a) it has to be done by hand; (b) it's not
particularly efficient; (c) it does not provide an easy way to 'reset'
the unknown key; (d) it does not apply _all_ of the 'foo' keys first, so
may not behave as expected. (On the last point, I'd actually favour
sticking with 'set keys in the order given', as the order is often
important even without filtering.)

I'm not sure if a separate \keys_filter: function is needed, or what is
better is an extension to \keys_define:nn such that \keys_set:nn gains
additional abilities. Taking the later approach, we might introduce a
".redirect:n" property:

  \keys_define:nn { foo }
    {
      unknown .redirect:n = { bar }
    }

With this approach, we'd need to decide whether to wait until the end of
the 'parent' \keys_set:nn run before doing the redirections, or to do
the setting 'now', or indeed whether we need both variants. As I say, at
the moment I'd go with 'interleaved' setting. You can also imagine
extending such a property to named keys.
-- 
Joseph Wright