MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4DCA93CC.5020605@morningstar2.co.uk>
            <19920.15087.714131.100464@morse.mittelbach-online.de>
            <447088.31292.qm@web24704.mail.ird.yahoo.com>
            <BANLkTinwYoQLJzWWfq0E47OJi-V3+8kQTQ@mail.gmail.com>
            <4DD0BFB3.7070007@morningstar2.co.uk>
            <27DAD3FD-9C28-4707-9454-FBB65B66A56D@gmail.com>
            <4DD0D8F4.7030101@morningstar2.co.uk>
            <4DD11D50.6000901@residenset.net>
Message-ID:  <19921.40225.730390.362395@morse.mittelbach-online.de>
Date:         Mon, 16 May 2011 23:54:41 +0200
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: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: xparse and space skipping
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4DD11D50.6000901@residenset.net>
Precedence: list
Status: R

Lars wrote

 > 2. Sometimes, an existing command is redefined so that an optional 
 > argument is added at the end. In such cases, it may be preferable to make 
 > that argument such that it does not skip spaces, for compatibility with 
 > existing documents written under the assumption that spaces would not be 
 > skipped at that point. In other words, if
 > 
 >     \bar{apa} cepa
 > 
 > used to have a space, and \bar for some reason in a package needs to be 
 > extended to support \bar{apa}[bepa], then \bar{apa} cepa should still have 
 > that space.

in this particular case it would indeed be a bad change if a package "extends"
a command in this way and the result is the loss of spaces in a document.
On the other hand I don't think that a package author doing this would get
very happy customers


 > Therefore, the solution should be to provide both, but let the 
 > space-nonskipping variants come with a big warning in the xparse 
 > documentation, detailing why they are usually inappropriate. In 
 > particular, such documentation should suggest the argument order
 > 
 >    \bar[bepa]{apa}
 > 
 > as preferable to
 > 
 >    \bar{apa}[bepa]
 > 
 > since package authors are otherwise likely to pick one at random, never 
 > even considering the syntactical implications.

This might be an option for a compromise (in fact you could even force this to
be only available in the last argument at some technical cost, though I would
advice to not go that far but put in big guidelines)

something  to think about a bit further I guess (but not tonight)

frank