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
Condense Mail Headers

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

Print Reply
Mime-Version:
1.0
Content-Type:
text/plain; charset="us-ascii"
Date:
Tue, 23 Aug 2011 13:03:38 +0200
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
Content-Transfer-Encoding:
7bit
Message-ID:
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
From:
Ulrike Fischer <[log in to unmask]>
Parts/Attachments:
text/plain (73 lines)
Am Tue, 23 Aug 2011 11:10:02 +0100 schrieb Joseph Wright:

> On 23/08/2011 09:32, Ulrike Fischer wrote:
>> I don't have enough practice with l3keys to decide this - just
>> starting. But from the language I would expect a \keys_set_known to
>> give an error if it encounters something unknown. Also a command to
>> set keys can set only known keys, so it sound like a pleonasm. 
> 
> Well no, as the special 'unknown' key allows behaviour for a key which
> is not defined to be set up.

Does keys_set_known makes a difference between modules with and
without such an unknown key?  

> 
>> Another question: pdfkeys has the notion of a "key tree" and
>> "pathes". And you can switch pathes with a command. (.cd I think).
>> Can/should one do something similar with l3keys? I see the
>> subgroups, but I'm not sure if they really are the same conzept.
> 
> Internally, l3keys uses the same storage approach as pgfkeys. The
> \keys_set:nn macro is rather more like \pgfqkeys than \pgfkeys, in the
> sense that it includes a root to search from. It is therefore possible
> to do something like
> 
>   \keys_set:nn { } { foo / key-a = value , bar / key-a = other-value }
> 
> So it would in principal be quite possible to implement
> 
>   \keys_set:n % No starting path
>     { / foo .cd: , key-a = value , bar .cd: , key-a = other-value }
> 
> However, at the moment there's not been a good use case for l3keys for
> such an approach. Explaining keys as a tree is not so easy as dealing
> with each modules keys separately.

I'm currently changing chessfss to keyval-syntax. I have to set
properties for board fonts, figurines fonts and other symbols. So I
have a structure like this:

all chess fonts
  family
  width
  series
  size
  
fig font
  encoding
  family
  width
  series
  size

board font
  encoding
  family
  width
  series
  size

...

So keys like "fig / encoding" look quite natural, but it would be
quite useful if a user could set keys also like this:

set-all, family=...

set-fig, family=...  , size= ...


-- 
Ulrike Fischer 

ATOM RSS1 RSS2