LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text 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: Mon, 8 Sep 2008 20:15:52 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Subject: Re: keyval
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
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 (54 lines)
Morten Høgholm wrote:
> On Sat, Sep 6, 2008 at 9:43 AM, Joseph Wright
> <[log in to unmask]> wrote:
>> I've been looking at the current expl3 work, and I'm wondering about the
>> planned direction with keyval stuff.  The current l3keyval only covers
>> some very basic functions, and it's not clear to me whether this will be
>> extended to higher-level commands.
> It will. So far only data extraction was done because a) it was needed
> and b) I need to sit down, preferably with someone, and take a good
> look at how to tackle this. Judging from the hacks we see in pstricks
> and many other packages, the current approach as implemented in keyval
> is insufficient. The model used in pgf looks interesting.

I agree.  I think overall the idea of separating "properties" of keys is
much bettr than (say) xkeyval.
> How the keyvals are used depends on the circumstances. If you take a
> look at template, it both runs traditional "turn key into csname, then
> assign it a value" but also contains a more complex run when declaring
> the template. In the latter instance, the value in fact consists of
> individual values, each requiring different action.

That might be a challenge.  I was mainly thinking about providing a way
for programmers to set up options, etc.  I suspect template will push

>> [snip] if no-one else is likely to
>> work on this in the near future I can perhaps see whether I can produce
>> some basic macros in this area (for preference I'd probably adopt the
>> pgfopts model, which I find quite accessible).
> Please do go ahead.

Okay, I will have a look at this.  For first preference, I might use the
pgfopts syntax:


although I suppose:




might both be more in line with the LaTeX3 system. However, I think the
analogy with UNIX paths works quite nicely for the pgfopts approach.
Joseph Wright