User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17)
            Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
References: <4DCA93CC.5020605@morningstar2.co.uk>
            <BANLkTi=qwNmk+ZmhbV70LCdhZkX57_QDaA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4DCAE189.9020204@morningstar2.co.uk>
Date:         Wed, 11 May 2011 20:20:41 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: xparse and space skipping
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <BANLkTi=qwNmk+ZmhbV70LCdhZkX57_QDaA@mail.gmail.com>
Precedence: list
Status: R

On 11/05/2011 20:01, Bruno Le Floch wrote:
> Not quite true. For instance, amsmath redefined \\ not to skip spaces
> when looking for an optional argument, I believe. And that works
> because \\ is a control symbol, not a control word. I think this
> choice of behaviour really needs to be supported, since it leads to
> surprises for the end-user otherwise.
> 
>> really correct! (At the same time, the implementation would be slightly
>> easier to follow if this change was made.)
> 
> On the other hand, emulating LaTeX2e arguments with space skipping
> seems needed as well. Is it possible to get the best of the two worlds
> with a "o_no_skip" argument specifier? Or more generally a modifier,
> say K, which makes the next argument keep spaces (except perhaps for m
> arguments where it should produce an error)?
> 
> \DeclareDocumentCommand {\\} { Ks Ko } {...}

We did do that at one point, but the problem then became that there is
not a hard-and-fast rule. (While the AMS might be very clever in their
redefinition, I'd prefer to be consistent with things like the classic
"\item [" case even if it means rembering to do "\item{} [" and "\\{} [".)

(As a user, I'd like to see one reliable syntax, and not have to read
package documentation to explain why in one case "\foo{...} [...]" works
but in another case "\baz{...} [...]" fails.)
-- 
Joseph Wright