Will Robertson 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?)
Oops, yes, Will is correct. The idea here was "optional braced
argument" (partly for the reasoning that, as Lars says, [ ... ] is
user-level mark up).
> 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.
That was my thinking: it also means that the \IfNoValue test knows what
to look for!
>> 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.)
The main reason for keeping a letter for (x,y) is that it can be a
mandatory argument in LaTeX2e, so needs special handling.
> 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.
Okay, I'm sure we can work that in. "n" seems as good a letter as any.
>> 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.
My main concern is "should we provide the option to change things"?
Would it be clearer if the same rules always apply (is there a need to
skip spaces to find trailing optional arguments, for example).
--
Joseph Wright
|