Cfrgtkky

I encountered a peculiarity concerning NewDocumentCommand arguments.
In a case where I had real long names in the arguments, I wanted to put
them each on its own line. The first ones are OK, the 2 last ones are
problematic, as shown in the MWE. Is this the normal behaviour or is it a
bug or am I doing something stupid?

documentclass{article}

usepackage{xparse}

%                           12  3        4          56     

NewDocumentCommandTestArg{st+ O{empty}D(){empty}mD()%

                              {empty}O{empty}}{%

%                                     7

noindent

3: #3 \

4: #4 \

5: #5 \

6: #6 \

7: #7

}

begin{document}

TestArg[Three](Four){Five}(Six)[Seven]

parvspace{2baselineskip}

TestArg

[Three]

(Four)

{Five}

(Six)

[Seven]

end{document}

Let's consider a simpler example:

documentclass{article}

usepackage{xparse}



NewDocumentCommandTestArg{mO{x}}{%

  1: #1, 2: #2

}



begin{document}



TestArg{a}[b]



TestArg{a} [b]



end{document}

This produces

You can clearly see that in the second case [b] is not recognized as an optional argument; instead, the default value x is used and [b] is printed separately, with a space in front of it.

A new line counts as a space, so it's not a surprise if also

TestArg

{a}

[b]

produces the same result.

This was a precise choice when the interface of xparse was developed. The team followed the example of amsmath that doesn't allow spaces in front of optional arguments to \, because of the infamous

left[begin{array}{cc}

1 & 2 \

[1] & [2]

end{array}right]

that raises an error, because [1] is mistaken for the optional argument to \. Instead

begin{bmatrix}

1 & 2 \

[1] & [2]

end{bmatrix}

works flawlessly.

The input TestArg{a} [b] is deemed ambiguous. There were two choices, the team followed the path of considering [b] not an optional argument.

You get the same behavior with

documentclass{article}

usepackage{xparse}



NewDocumentCommandTestArg{mD(){x}}{%

  1: #1, 2: #2

}



begin{document}



TestArg{a}(b)



TestArg{a} (b)



end{document}

In my opinion, one should never define macros with seven arguments. In your case two are for the variants, four are optional and one is mandatory.

A key-value interface would be much better:

TestArg[

  var-a=true,

  var-b=false,

  opt-A=Three,

  opt-B=Four,

  opt-C=Six,

  opt-D=Seven,

]{Five}

By the way, {empty} does not specify an empty default value: if tested with tl_if_empty:nTF{#3}, a missing first optional argument would make LaTeX follow the false branch.

you can not have white space before optional arguments that follow the last mandatory argument so this works.

documentclass{article}

usepackage{xparse}

%                           12  3        4          56     

NewDocumentCommandTestArg{st+ O{empty}D(){empty}mD()%

                              {empty}O{empty}}{%

%                                     7

noindent

3: #3 \

4: #4 \

5: #5 \

6: #6 \

7: #7

}

begin{document}

TestArg[Three](Four){Five}(Six)[Seven]

parvspace{2baselineskip}

TestArg

[Three]

(Four)

{Five}%

(Six)%

[Seven]

end{document}

This is by design so that (like the optional arguments in amsmath) you do not get mis-interpretation in things like

.... 25\

[foo] & 26 \

where [foo] is intended to be the data in the array cell, not an argument to \

With the latest release of xparse, you will find that the b is picked up as you expect. We have refined the treatment of trailing optional arguments such that spaces can be allowed or forbidden:

documentclass{article}

usepackage{xparse}

NewDocumentCommandTestArgOne{m O{x}}{%

  1: #1, 2: #2

}

NewDocumentCommandTestArgTwo{m!O{x}}{%

  1: #1, 2: #2

}



begin{document}



TestArgOne{a}[b]



TestArgOne{a} [b]



TestArgTwo{a}[b]



TestArgTwo{a} [b]



end{document}

As you will see, TestArgOne grabs the [b] as an optional argument whether or not there is a space. In contrast, for TestArgTwo I have used the syntax !O{x}, where the ! means that the optional argument has to follow immediately with no space. This controllable behaviouris useful as depending on the use case, a space may or may not make sense. (The classic example is \[...], which is used in math mode and where a space or newline before the [ means something very different.)