MIME-Version: 1.0
References: <CAM2dePV5k2+Q+H=jCj=bsvc-hWanc3_CLYw1-ukhB8UMhzU_Lw@mail.gmail.com> <51C94FA0.1080803@morningstar2.co.uk>
            <CAM2dePUfzF_Bj5QX7qbAmsyO7Udjy1yb5j43zTVexOwG2rmtVQ@mail.gmail.com> <51DD0EBD.6080308@morningstar2.co.uk>
            <CAM2dePUxFs1eNU1iTCrnp=CbDFo1eMjE813gZQH3vVhBkH=zDg@mail.gmail.com>
            <51DF2000.30703@morningstar2.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <CAM2dePW67rUcSRqRYEeccS6AUVmGjW5XuY74ZCYPfgqObK=BcA@mail.gmail.com>
Date:         Thu, 11 Jul 2013 22:57:20 -0400
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: Jura Pintar <pintar@POST.HARVARD.EDU>
Subject: Re: l3keys feature request
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <51DF2000.30703@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

> My thinking with this is that you can simply do a 'filtered' or
> 'grouped' setting without having to track when filtering is on/off.

Yes, I did have a feeling that that bit was overkill given the limited purpose.

> The above interface leaves open a few questions:
>
>  - How is nesting handled? Does \keys_set:nn within
>    \keys_set_grouped:nnn respect groups? Does
>    \keys_set_grouped:nnn within \keys_set_grouped:nnn
>    work in a union or intersection way?

I'd say, 'yes' to the first (that would be closest to what is done in
pgfkeys), and given that, 'intersection' to the second.

>  - Do unknown keys raise an error, or are they ignored as they
>    are not in any group?

Following pgfkeys again, I think they should raise an error.

>  - Do unused options need to be collected/available?

I've not had the occasion to use this myself, but pgfkeys does provide
it. One application that immediately pops to my mind is the control of
key-setting order when the order is important, which is potentially
rather useful. So why not have \keys_set_grouped:nnnN, allowing
something like:

\cs_new_protected:Npn \__mymodule_keys_set_in_order_and_do_something:n #1
  {
    \keys_set_grouped:nnnN { mymodule } { must-be-set-first }
      {#1} \l__mymodule_keys_leftover_clist
    \__mymodule_do_something_first:
    \keys_set:nV { mymodule } \l__mymodule_keys_leftover_clist
    \__mymodule_do_something_else:
  }

which is then used inside a document command. One could add an F
branch to \clist_if_in:Nv inside \__keys_set_elt_grouped: that adds
the expanded \l__keys_key_tl of the filtered keys to an
\l__keys_filtered_clist and then \tl_set_eq:NN that to the last
argument of \keys_set_groups:nnnN (\l__keys_filtered_clist should,
naturally, be cleared somewhere, e.g. at the start of the new
\__keys_set_grouped:nnnnnn).

Another question is what should happen to keys that haven't been
assigned a group. Right now, they're filtered out, but perhaps it
would be better to set them. In that way, if there are keys that
should never be filtered, they won't need to be assigned a fallback
group to accomplish this. Pgfkeys provides both options, but it seems
to me it's easier for package writers using l3keys to just follow the
principle that they should assign a key to a group only if they ever
want to filter it out. This ties in with one aspect of how the draft
\keys_set_groups:nnn behaves that I feel should be definitely changed.
Right now, when the second argument is empty, all the keys get set,
which is the opposite of what one would expect. I think, instead, no
keys should be set, except for those that have no group assigned to
them. I believe changing \tl_set:Nx \l__keys_groups_clist {#4} to
\tl_set:Nx \l__keys_groups_clist { , #4 } in the definition of
\__keys_set_grouped:nnnnn would do this.