I really wish that the positional thing was somewhat deprecated in favor of a named argument approach, which would replace the limit of 9 at some point. Paul Thompson Professor and Senior Scientist Director, Methodology and Data Analysis Center Sanford Research 900 W Delaware Sioux Falls, SD 57104 O: 605-312-6462 M: 618-974-0473 H: 605-332-1587 F: 605-328-0401 909 N. Charleston Circle Sioux Falls, SD 57110 605-332-1587 ________________________________ From: Frank Mittelbach <[log in to unmask]> To: [log in to unmask] Sent: Mon, May 16, 2011 4:41:54 PM Subject: Re: xparse and space skipping > On 16/05/2011, at 3:39 PM, Joseph Wright wrote: > > > To me, that means > > > > \foo[...]{...} > > > > is a possible, but I'd hope not > > > > \foo{...}[...] > > I think there are enough examples on CTAN where people have needed to > extend the optional argument syntax to indicate that the 2e model above is > too restricted for user purposes. --text follows this line-- A simple syntax with unnamed positional arguments (optional or mandatory or mixed) as 2e provides it has its uses and they go beyond a single optional argument. But clearly this is a syntax that very fast gets difficult to use or rather to remember. It all depends on how strong the arguments are "naturally ordered" and how often such commands are used. > > Having said that, I do agree in some cases (such as \makebox[][]{}) an > overload of optional arguments is also a bad idea, where a keyval interface > makes more sense. I guess there are worse ones but yes, those kind of commands are good examples were such a syntax is fast reaching its limits especially as the commands are seldom used. But if a command is used often enough you can keep a consise syntax and still have it fairly complex. Anyway, I'm not arguing key/val no key/val. I'm quite a fan of the letter (sometimes) > Dropping trailing optional arguments just doesn't feel right to me; in the > interests of disclosure, however, at least two of the packages I've written > (pstool and mlist) use them, so I'm clearly biased :) Their interfaces > could certainly be revised but I don't think (yet) in hindsight that the > way the commands work therein is necessary a bad idea. I wouldn't drop them either (not for xparse anyway) and I think that Lars' suggestions needs a closer look at to perhaps provide the best of both worlds even here. frank