User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509
            Thunderbird/17.0.6
MIME-Version: 1.0
References: <CAM2dePV5k2+Q+H=jCj=bsvc-hWanc3_CLYw1-ukhB8UMhzU_Lw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Message-ID:  <51C94FA0.1080803@morningstar2.co.uk>
Date:         Tue, 25 Jun 2013 09:06:56 +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: l3keys feature request
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CAM2dePV5k2+Q+H=jCj=bsvc-hWanc3_CLYw1-ukhB8UMhzU_Lw@mail.gmail.com>
Precedence: list
Content-Transfer-Encoding: quoted-printable
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Hello Jura,

On 14/06/2013 11:05, Jura Pintar wrote:
> Dear all,
>=20
> I=92ve recently been re-implementing some of my projects in L3, and
> finding myself having to jump through some hoops to get things I had
> working smoothly in pgfkeys work equivalently well with l3keys. In
> particular, filtering and redirecting keys has been a bit of a chore.

I'm not entirely surprised: pgfkeys is 'object oriented' in a way that
l3keys is not. I also wrote most of it at a time when filtering in
pgfkeys was not developed, so did not even have this in mind as part fo
the process.

> In
> light of this, I have a couple of suggestions for features that could b=
e
> added to the module in due course (to better illustrate what I have in
> mind, I=92ve written a quick-and-dirty implementation - appended at the
> bottom of this email; the code seems to work, but I fully expect more
> experienced people could greatly improve it).

Most of the l3keys properties are just wrappers around .code:n, so I
wouldn't bet on it :-)

> 1) It would be good to add a .meta:nn property that takes a path as its
> first argument, so that we could do things like
>=20
>   \keys_define:nn { module / subgroup-i }
>     { key-i .code:n =3D { < code > } }
>   \keys_define:nn { module / subgroup-ii }
>     { key-ii .meta:nn =3D { module / subgroup-i } { key-i =3D #1 } }
>=20
> instead of having to write
>=20
>   \keys_define:nn { module / subgroup-ii }
>     { key-i .code:n =3D { \keys_set:nn { module / subgroup-i } { key-i =
=3D #1 } } }
>=20
> as is the case right now.

Sounds reasonable: anyone else have a view before I add it?

> 2) It would also be useful to provide a \keys_set_in_subgroups:nnn
> command which would take a list of subgroups in the second
> argument-place, and would cycle through all the subgroups looking for
> keys given in the third argument-place. Then we could write things like
>=20
>   \keys_set_in_subgroups:nnn { module } { subgroup-i , subgroup-ii }
>     { key-i =3D foo , key-ii =3D bar }
>=20
> instead of
>=20
>   \keys_set:nn { module / subgroup-i } { key-i =3D foo }
>   \keys_set:nn { module / subgroup-ii } { key-ii =3D bar }
>=20
> More importantly, we could then easily define user commands that set
> different subsets of keys. A further command  \keys_set_known_in_subgro=
ups:nnnN
> could then be used to catch keys that don=92t exist in any of the
> specified subgroups. If this suggestion is accepted, it would also be
> useful to then extend l3keys2e with something like
>=20
>   \ProcessKeysOptionsInSoubgroups { < module > } { < subgroup list > }
>=20
> so we can use filtering in this context as well.
Here I'm less certain, both in functionality and name terms. I wonder if
we might have a real-life use case for this?
--
Joseph Wright