LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Wed, 16 Sep 2009 09:02:33 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=ISO-8859-1
From: Joseph Wright <[log in to unmask]>
Parts/Attachments: text/plain (58 lines)
Joseph Wright wrote:
> Hello all,
> 
> The ongoing template discussion has prompted me to think again about
> some aspects of l3keys. It's pretty clear to me that the aims in l3keys
> are rather different from those in template. l3keys is really about
> creating keys for the programmer, so it can take a very different
> approach to template.
> 
> Several things have come up in the discussion, and I'd like to see how
> other people feel about the following before doing anything:
> 
> - I added .initial:n and .initial:V mainly with template in mind. In
> l3keys, initial values can be set using \keys_set:nn, and overall I feel
> this is probably clearer (separate key definition from key setting). I'd
> therefore like to drop .initial:n/V
> 
> - There is .function:N which again was more about template than l3keys.
> I'm not sure the property is actually very clear (it does \cs_set:Nn
> <function> { <key-value }), so again I'd like to remove it.
> 
> - There are currently a .code:n and a .code:Nn property, where the
> former only takes one argument and the later takes N. To be honest, I
> think it might be better to only have .code:n so that if further
> splitting of a value is needed it is done elsewhere, and not by l3keys.
> 
> - Related to the .code:Nn point, .generate_choices:nn also splits the
> value part of a key-value argument in two. I'm no longer sure this is a
> good thing, so perhaps
>   .choice_code:n       = <code>,
>   .generate_choices:n  = <choices>
> would be better.
> 
> - Not everyone likes the .set:N idea of detecting the variable type and
> scope from the variable name, rather than having .tl_set:N, .int_gset:N,
> etc. As we are talking about a programmer function, it's not
> unreasonable to read the variable information from the name. It's easy
> to go back to the previous method if that is the consensus.
> 
> I'd like to get this sorted out soon (i.e. in the next week) as I am
> using l3keys for siunitx v2 and as Manuel has indicated he is also
> looking at using l3keys for real work.

I've made the changes outlined above. At present, I've retained .set:N
and added
 - .dim_(g)set:N
 - .int_(g)set:N
 - .skip_(g)set:N
 - .tl_(g)set:N
 - .tl_(g)set_x:N

Is everyone OK with retaining .set:N in this way, or would others prefer
only to have the explicit setting properties? I'd like to update the
CTAN version soon to reflect these changes (which I hope are the final
ones for l3keys), and so want to get this right.
-- 
Joseph Wright

ATOM RSS1 RSS2