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:
Will Robertson <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 11 Jun 2009 17:18:46 +0930
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (2399 bytes) , smime.p7s (2446 bytes)
Hi all,

Some rambling general comments below.

On 11/06/2009, at 5:08 AM, Joseph Wright wrote:

> The spaces really should not be an issue: it
> is all building things from csname.

I've even toyed with the idea, when dealing with keyval input in  
fontspec, (never happened though) of normalising all keyval input by  
stripping spaces and hyphens, and lowercasing the result. So the  
following would all be equivalent:
   number case=
   NumberCase=
   Number-case=
and so on.

Not actually sure if that would be a good idea (one person commented  
something like "why reward the user for incorrect input?"). Easier for  
the user, however, who must deal with multiple packages in which one  
has CamelCaseKeys, another "keys with spaces", another with  
keysruntogether.

* * *

Regarding keys3 vs template, I'm still firmly on the fence. I think I  
need to implement something reasonably complex from scratch and see  
how both fare. One thing that template seems to do nicely is  
inheritance; what would be the equivalent process in keys3?

To the advantage of keys3, I agree that being able to change the  
default value of a key independently is very desirable. Another  
feature that template doesn't support as easily is the idea of an  
explicit set of named options such as keys3's .create_choices:nn and  
xkeyval's \[log in to unmask]

* * *

I'd like to explore the idea of auto-detecting the variable type (by  
stripping off and examining the trailing "_xyz" of the variable) to  
determine which _set function should be used; this could simplify many  
of the common use cases for both packages. Since it would only need to  
be done when first setting up the key, the performance hit should be  
completely reasonable.

After all, what's the point of having some nicely rigid naming schemes  
if we never take advantage of them? :) But even better is that this  
scheme could allow assignments to other types of variables (such as  
clists) without any extra work.

E.g.,

\keys_manage:nn {module/caption/} {
    above-skip/.set:N = \l_caption_above_skip ,
    above-skip/.default:n = 5mm ,
    caption-name/.set:N = \l_caption_name_tl ,
    caption-name/.default:n = {Figure}
}

or

\DeclareTemplate{module}{caption}{4}{
   above-skip = n [5mm] \l_caption_above_skip ,
   caption-name = n [Figure] \l_caption_name_tl
}{...}

* * *

Anyway, what I've said above doesn't really help the discussion much  
but it might spark a couple of new ideas.

Will



ATOM RSS1 RSS2