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