LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sat, 26 May 2012 20:46:46 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
Content-Type:
text/plain; charset=ISO-8859-1
From:
Joseph Wright <[log in to unmask]>
Parts/Attachments:
text/plain (57 lines)
On 26/05/2012 16:12, Marco Daniel wrote:
> Hello,
> 
> Today I noticed that there is no key .initial:n. This question popped up
> during writing a small package. Whatever at the moment you have the
> following possibilities to set a key-value-syntax with an initial value:
> =======================================================================
> %First approach:
> 
> \keys_define:nn { module }
>  {
>   myoption .int_set:N  = \l_modul_myoption_int
>  }
> \keys_set:nn  { module }
>  {
>   myoption = 2
>  }
> \ProcessKeysOptions { module }
> 
> =======================================================================
> Second approach
> 
> \keys_define:nn { module }
>  {
>   myoption .int_set:N  = \l_modul_myoption_int ,
>   myoption .default:n  = 2
>  }
> \keys_set:nn  { module } { myoption }
> \ProcessKeysOptions { module }
> 
> =======================================================================

Note that this are not equivalent when you consider the behaviour later
on. In the second case, giving "myoption" is the same as "myoption = 2",
but in the first case the two are distinct.

> I suggest to define a new key .initial:n so that we have a third approach:
> 
> Second approach
> 
> \keys_define:nn { module }
>  {
>   myoption .int_set:N  = \l_modul_myoption_int ,
>   myoption .initial:n  = 2
>  }
> \ProcessKeysOptions { module }
> 
> =======================================================================

At one point we did have this. Checking back through the archive, I
removed it as it did not seem to add anything to the two-stage process.
However, that was not a 'strong' objection: I was simply trying to keep
the number of properties down as far as possible. If this looks like a
useful addition I've no problem adding it back in: anyone else have a view?
--
Joseph Wright

ATOM RSS1 RSS2