LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Mon, 16 May 2011 23:54:41 +0200
text/plain (42 lines)
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)