Is it intentional that you cannot skip lines when using optional environment parameters with LaTeX3's xparse?

It seems that you can skip lines with mandatory parameters.



\NewDocumentEnvironment{mandatory}{ m m m }
{#1\par #2\par #3}

\NewDocumentEnvironment{optional}{ O{first} O{second} O{third} }
{#1\par #2\par #3}



\begin{optional} %<- Here is the problem child.




enter image description here

  • 2
    Yes, it is intentional; the rationale is that you may want a [ that's not interpreted as the start of an optional argument. Anyway, trailing optional arguments for “document commands” is not recommended. This appeared first in amsmath for \\ on a line and [ on the following line, say of an align. – egreg Aug 24 '15 at 13:35
  • @egreg Ok, that makes sense. My use of trailing arguments is to create an environment that will go at the beginning of every document that contains certain required metadata that when not provided, show up in the document in nice bright letters for all to see (demonstrating that this info is indeed missing). parameters: <privacylevel> <target group> <purpose> I thought it would be better to let the parameters trail, because two of those mentioned contain paragraphs. It was purely a readability issue (in the code). – Jonathan Komar Aug 24 '15 at 13:42
  • I'd advocate a key-value interface for this. – egreg Aug 24 '15 at 13:43
  • @egreg Would you consider making your comment an answer so that I can close this question? When you have time... – Jonathan Komar Aug 31 '15 at 9:10

It is intentional, but, as far as I know, there are still discussions about it.

The problem appeared several years ago within amsmath, when something like

a &= b \\
[c] &= d

was considered. With the default LaTeX setup, this triggers an error (Missing number, treated as zero), because \\ would ignore spaces when looking for its optional argument. So the developers of amsmath decided to use a different version of \@ifnextchar that requires no space to intervene between \\ and its optional argument.

A similar approach is used in xparse, but only for environments, as far as I can see. So








would turn out in bad output only for the second foo environment call, where

START:xy [A] [B] C END

would be printed.


A workaround, not a recommendation, would be

  { O{first} t\@sptoken O{second} t\@sptoken O{third} }
  {#1\par #3\par #5}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.