0

I know that the following is not something you are usually supposed to do, but I ask anyway: I am getting quite tired of the fact that TeX does not treat the content of brackets [...] as groups like {...}. This is getting annoying when writing math with lots of nested keyval interfaces, where stuff like

\command[key=\othercommand[otherkey=7]]

dies horribly. In other words, you have to wrap the key in braces:

\command[key={ \othercommand[otherkey=7] }]

I wonder: Does it have to be this way, or could you in principle make [...] behave like group separators (like {...}) and still make optional arguments like in xparse work? I am well aware that stuff like $[a,b)$ would not work and would have to be replaced by $\lbracket a,b)$, but I’m fine with that.

I tried something like the below, which obviously failed horribly:

\documentclass{article}

\usepackage{xparse}

\let\oldopenbracket=[

\let\oldclosebracket=]

\def\MakeBracketsStrict{ \catcode[=13 \catcode]=13

\def[{\oldopenbracket\noexpand\bgroup}

\def]{\oldclosebracket\noexpand\egroup}

}

\def\MakeBracketsNormal{ \catcode[=12 \catcode]=12 }

\begin{document}

\DeclareDocumentCommand\test{ mo }{we test #1 and #2}

\MakeBracketsStrict

\test{foo}[bar]

\MakeBracketsNormal

\test{foo}[bar]

\end{document}

Gaussler
  • 12,801
  • You could try \def\command[#1]{content for #1} including brackets in your definition. Playing with catcodes in LaTeX is quite unsafe. –  Jul 01 '20 at 12:54
  • @JairoADelRio I need a general solution that works with xparse and similar packages. But I am aware that this might not be possible. Indeed, this can be unsafe, which is why I also want a command \MakeBracketsNormal to turn it off again. – Gaussler Jul 01 '20 at 12:57
  • 1
    I made a similar question before (it seems not to have an easy solution). A better solution would be using a keyval package –  Jul 01 '20 at 12:58
  • @JairoADelRio I am already relying on a keyval solution, namely the one in expl3. It does not solve the problem of nested equality signs when using brackets as optional arguments. – Gaussler Jul 01 '20 at 13:10
  • TeX doesn't treat {...} as a group when absorbing an argument; moreover \bgroup and \egroup are no substitute for {...} as argument delimiters. I'm not really understanding what you're after. – egreg Jul 01 '20 at 13:15
  • @egreg Maybe I am using the wrong vocabulary. What I want is for TeX to always treat [...] as pairs so that \command[key=\othercommand[otherkey=7]] would work. Right now, any key value package (including l3keyval) will fail because it found two equality signs inside the optional argument. – Gaussler Jul 01 '20 at 13:28
  • Use \command[option={\anothercommand[anotheroption=...]}], with braces, if you want to embed a keyval into another one, in case it is possible –  Jul 01 '20 at 20:15
  • @JairoADelRio I know, as I also mentioned in the original post above. The whole point was to find out if this could be avoided somehow. – Gaussler Jul 02 '20 at 06:43

0 Answers0