Print

Print


Joseph Wright writes:
 > You may remember that a while ago we discussed space skipping for
 > optional arguments with xparse, for example
 > 
 >    \foo{mandatory}[optional] other text
 >    \foo{mandatory} [optional] other text
 >    \foo{mandatory}  other text
 > 
 > At the time, the feeling was that we should not skip spaces in these
 > cases, so only the first of my examples is parsed as containing an
 > optional argument.

Must confess that I can't remember that discussion nor the feeling that
resulted from it, but regardless of what I may have argued for in that
discussion (if I was part of it) looking at the above scheme I don't think I
like it or think it would be helpful.

For starters in my opinion xparse is a module made to largely mimic the look
and feel of current 2e document level approach and what you describe here is a
strong deviation from that. (this is independent of the fatc that there may be
a completely different approach to document level syntax, eventually, but this
is not what xparse was meant to be).

In a syntax of that sort, there needs to be good ways to naturally break up a
command and its arguments in different lines and a natural way to do that is
to break between arguments (rather than inside) often even putting longer ones
on single lines,eg

   \foobarbaz {aaaaaaaaaaaaaaaaaaaaaaaaa}
              [bbbbbbbbbbbbbbbbbbbbbbbbb]
              [ccc]

or even

   \foobarbaz
     {aaaaaaaaaaaaaaaaaaaaaaaaa}
     [bbbbbbbbbbbbbbbbbbbbbbbbb]
     [ccc]

To be forced to keep the arg boundaries on a single line or add %s all over
the place is just not the way people currently use LaTeX (besides I think it
rather looks fairly ugly and unreadable).

And 2e is consistent here. They only well-known exception is \\ in the amsmath
reimplementation. To my knowledge this is really the only exception - if I'm
wrong please somebody tell me what else is not following the general skipping
of spaces scheme.

Now one could argue that that this  behavior for \\ is useful (especially in
math for which amsmath reimplements it) but realistically what are the other
places that need this kind of behavior?

The problem is this type of behavior is really most wanted in fairly simple
commands, say with just one optional argument or just a single star plus
perhaps optional argument. And there you run into the snag that you either
have to implement a full blown scanner yourself and  disable TeX's internal
scanner completely (such as turning anything into catcode 13 and assemble
everything yourself). Of course that is possible, but ...

If you don't want to go that far then commands like \linebreak etc will always
suffer from the fact that there will be spaces allowed between them and a
following [.

And in fact the general sentiment of this all needs to be configurable
individually for any command is in my opinion a bad guide. It just mean that
nobody knows what will happen on many commands as there is no rule other than
looking up how there are defined. And in my opinion this makes up an ugly user
interface. 

here is my summary

allow spaces but not \par between arguments
===========================================

pros
 - consistent
 - like 2e
 - easy to remember
 - makes for readable sources on the whole

cons
 - would not support the \\ case as implemented by amsmath


do not allow spaces between arguments
=====================================

pros
 - consistent
 - easy to remember
 - would support the \\ case as implemented by amsmath

cons
 - completely different to 2e behavior
 - makes for fairly unreadable sources on the whole


leave it to the command how spaces between arguments are interpreted
====================================================================

pros
 - would support the \\ case as implemented by amsmath
 - makes for fairly unreadable sources on the whole

cons
 - inconsistent interface
 - difficult to remember how individual commands behave
 - more likely to intorduce errors where you find argumnts ending up in text
by mistake


 > So looking again at this I think we should 'follow TeX', and be
 > consistent in skipping spaces in all cases. I don't like the fact that
 > at present there is a somewhat convoluted explanation of the behaviour
 > in the xparse documentation: this tends to show up when something is not
 > really correct! (At the same time, the implementation would be slightly
 > easier to follow if this change was made.)
 > 
 > Does this seem reasonable?

to me yes.

There would still be the question of control symbols viz control words. By
default a control symbol (e.g., \? \/ ...) will not skip spaces and \\
actually explicitly has code to scan and ignore spaces so was deliberately put
into the command class by Leslie to get a consistent interface for his main
commands (and amsmath changed it back).

But I find a single exception (if implemented) still preferable to the other
options.

frank