Mime-Version: |
1.0 (Apple Message framework v935.3) |
Sender: |
|
Subject: |
|
From: |
|
Date: |
Thu, 6 Aug 2009 11:13:21 +0930 |
In-Reply-To: |
|
Content-Type: |
multipart/signed; boundary=Apple-Mail-4-632861789; micalg=sha1;
protocol="application/pkcs7-signature" |
Reply-To: |
|
Parts/Attachments: |
|
|
On 05/08/2009, at 3:38 PM, Joseph Wright wrote:
> \DeclareDocumentCommand \foo { o[default] m } % now has a default!
Is the syntax to use square brackets or braces? (I thought the latter,
which is why I ask. As always, I prefer braces; what if the default is
to contain brackets?)
Lars mentions that he thinks the optional argument is unnecessary; I'm
not fussed either way, but I like the simplicity of being able to
write {o m} and having a standard boolean test to check whether it's
present or not.
> The current xparse implementation lets you create your own specifier
> letters. This is probably very risky: what if two packages use the
> same
> letter? I'd drop this idea.
One comment I have here is that in the future I don't see many people
defining weird combinations of arguments due to the prevalence of
keyval-style argument processing instead. I'd even think about
dropping coordinate-style parenthesis input like "(x,y)" based on
this. (Which can be emulated easily enough with "d()" and a clist
mapping in the input.)
On the other hand, I've been keen on the idea of an optional braced
argument. If it's an all-or-nothing decision about including
marginised option types, then I'd rather keep 'c' and also add 'n' (or
whatever) to represent that. Alternatively, I could write a separate
package for defining functions to accept a variable number of
arguments. We don't need to cram every possible functionality into
\DeclareDocumentCommand.
> Will has suggested that we should insist optional arguments follow
> directly on, with no spaces, to mean that:
>
> \foo*{arg} % #1 = TRUE, #2 = "arg"
> and
>
> \foo *{arg} % #1 = FALSE, #2 = "*"
>
> are treated differently. The idea here is that it makes LaTeX syntax
> more "regular", useful for translation to other formats. I think he's
> right, but wonder how others see it. The current xparse allows both
> space-skipping and non-space-skipping tests. I'd certainly say we
> should go with only one: either spaces are allowed or they are not.
Re-reading your approach in xparse-alt, I believe what is currently
implemented there is the best approach. It applies sensible defaults
and allows overrides; to whit:
{m o} does not skip spaces
{m o m} does skip spaces
{m !o} does skip spaces
{m ^o m} does not skip spaces
Since (a) can't always skip spaces, and (b) never skipping spaces
leads to inconsistencies, and (c) only need to ignore spaces when the
optional argument is last -- I strongly think xparse-alt has it right.
Will
|
|
|