LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Joseph Wright <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Tue, 25 Jun 2013 09:06:56 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (69 lines)
Hello Jura,

On 14/06/2013 11:05, Jura Pintar wrote:
> Dear all,
> 
> Iíve 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 be
> added to the module in due course (to better illustrate what I have in
> mind, Iíve 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
> 
>   \keys_define:nn { module / subgroup-i }
>     { key-i .code:n = { < code > } }
>   \keys_define:nn { module / subgroup-ii }
>     { key-ii .meta:nn = { module / subgroup-i } { key-i = #1 } }
> 
> instead of having to write
> 
>   \keys_define:nn { module / subgroup-ii }
>     { key-i .code:n = { \keys_set:nn { module / subgroup-i } { key-i = #1 } } }
> 
> 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
> 
>   \keys_set_in_subgroups:nnn { module } { subgroup-i , subgroup-ii }
>     { key-i = foo , key-ii = bar }
> 
> instead of
> 
>   \keys_set:nn { module / subgroup-i } { key-i = foo }
>   \keys_set:nn { module / subgroup-ii } { key-ii = bar }
> 
> More importantly, we could then easily define user commands that set
> different subsets of keys. A further command  \keys_set_known_in_subgroups:nnnN
> could then be used to catch keys that donít exist in any of the
> specified subgroups. If this suggestion is accepted, it would also be
> useful to then extend l3keys2e with something like
> 
>   \ProcessKeysOptionsInSoubgroups { < module > } { < subgroup list > }
> 
> 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

ATOM RSS1 RSS2