# Not ignoring spaces before optional argument with xparse

I am using xparse.sty to define a command that takes an optional argument in square brackets, and another one curly braces.

Problematically, it is not uncommon that the user will often want to begin the text after the command with square brackets. Since LaTex ignores spaces before the first optional argument, naively typing \myitem [not an argument] won't work, since "[not an argument]" will be considered an argument. MWE:

\documentclass{article}

\usepackage{xparse}

\ExplSyntaxOn

\NewDocumentCommand{\myitem}{ o g }{
\IfValueTF{#1}{%
[]-argument:~#1
}{
\IfValueTF{#2}{
\{\}-argument:~#2
}{
no~argument:~
}
}
}

\ExplSyntaxOff

\begin{document}
\myitem [Not intended as argument]
% Will output: []-argument: Not intended as argument

\end{document}


What's worse, because \myitem also takes a g argument, the standard technique for avoiding this issue (inserting a pair of braces before or around the text in square brackets) won't work eiter:

\myitem {}[Not intended as argument]
% Will output {}-argument: [Not intended as argument]

\myitem {[Not intended as argument]}
% Will output {}-argument: [Not intended as argument]


The only workaround right now is to use \relax before the square brackets, which I would like to avoid.

Is it possible to make LaTeX treat the spaces as terminating the argument list in this case? I.e., \myitem [foo] should output no argument: foo, while \myitem[foo] should (still) output []-argument: foo?

• Welcome to TeX.SX! Using g is provided, but it's not really recommended. Anyway, there is no space in \myitem [...], because of how TeX reads its input. – egreg Aug 27 '17 at 9:37
• It is not clear why there should be an optional argument delimited with {} in this case. What's the purpose of this? – user31729 Aug 27 '17 at 9:48
• @egreg: That is what I feared (seeing as similar problems would come with any g argument). So I might have to simply give up on using that argument. – Sven Lauer Aug 27 '17 at 10:08
• @ChristianHupfer Obviously, the command implementation is just a dummy for the sake of the MWE. In my package, I provide some enhancements (by means of different optional arguments) for and \item like command, and a g argument seemed like the natural choice for one them. Given this problem, I'll have to take that argument in another way (since I could live with users having to do the "standard technique" of using curly braces for avoiding that the part in square brackets is parsed as an argument). – Sven Lauer Aug 27 '17 at 10:12
• Thank you for your comments! Forgive my asking (I am new here), but what is the TeX.SX etiquette in cases like this, where the answer is simply "can't be done"? Obviously, there is no answer to "accept" ... – Sven Lauer Aug 27 '17 at 10:24

By the standard reading rules of TeX, there is no space even if you type

\myitem [abc]


because the space is ignored when the line is read in. A way out would be

\myitem\relax[abc]


because \relax will stop the scanning for optional arguments.

It has always been a problem when a command accepting an optional argument is followed by [. Note that xparse does its best in order to balance the ] of the optional argument, but it's a different problem.

Of course \myitem{[not optional]} would work as well if there wasn't a g optional argument.

In general, I wouldn't recommend this argument specifier: it has been added because some user interfaces (notably beamer) provide this convention. However, it is against the standard LaTeX interface and could be confusing: please, think well before adopting this kind of syntax.

• Thanks for extended explanation! I suppose this question (& answer) can serve as an illustration why using the g-parameters is not a good idea. – Sven Lauer Aug 27 '17 at 14:47
• Also Biblatex. At least, with the multi-cite commands, the first 2 {} arguments are required, but the next n arguments are optional .... – cfr Aug 27 '17 at 20:05