4

This may be a LyX rather than a LaTeX thing, but here goes.

I have this snippet of code which has a macro (\TE) within a macro (\PTV)

$\left(\PTV[\TE[i]]\right)$

As it should, this fails with the error 'Argument of \\TE has an extra }'. I figured out I can fix the problem by inserting a pair of curly braces around the \TE[i] part to have

\left(\PTV[{\TE[i]}]\right)

which works just fine, until I save, close and reopen the document.

I have discovered that LyX when opening removes the braces when loading into memory (according to the 'View Source' pane). I have been doing a bit of reading around the \protect command, but have not got it to work. I'm also not entirely convinced it is a protection issue, considering the document gets saved with the desired code (it's just reopening that is the issue).

Does anyone know what's happening? or how to force LyX to keep the braces when reading in the document? Or maybe a workaround?

EDIT: As requested, \TE is defined:

\newcommandx\TE[1][usedefault, addprefix=\global, 1=]{\gamma_{#1}}

And \PTV is defined:

\newcommandx\PTV[1][usedefault, addprefix=\global, 1=]{\boldsymbol{\tau}_{#1}}

EDIT2: Bug #10562 has been filed at https://www.lyx.org/trac/ticket/10562. Bug report includes a lyx file which is a minimum reproducible example of the bug.

EDIT3: I think I can now definitively say it is a bug with Lyx. Consider the following code:

\documentclass{article}
\usepackage{amsmath}
\usepackage{xargs}

\begin{document}
\newcommandx\TE[1][usedefault, addprefix=\global, 1=]{\gamma_{#1}}
\newcommandx\PTV[1][usedefault, addprefix=\global, 1=]{\boldsymbol{\tau}_{#1}}

$(\PTV[{\TE[i]}])$
\end{document}

Compiled using pdflatex in TexMaker, this compiles just fine. Import it into Lyx, and the issue I'm talking about occurs. I also note by moving the macros resolves the compilation issue in Lyx, but Lyx no longer recognises the macro (and therefore destroys one of the features of Lyx). i.e. :

\documentclass{article}
\usepackage{amsmath}
\usepackage{xargs}

\newcommandx\TE[1][usedefault, addprefix=\global, 1=]{\gamma_{#1}}
\newcommandx\PTV[1][usedefault, addprefix=\global, 1=]{\boldsymbol{\tau}_{#1}}

\begin{document}
$(\PTV[{\TE[i]}])$
\end{document}

Still not clear on why this is happening though...

4
  • 3
    How are \PTV and \TE defined? The dropping of braces sounds like a bug in LyX, so it might be worth reporting it at lyx.org/trac. Feb 13, 2017 at 10:32
  • Edited as requested.
    – Charlie
    Feb 13, 2017 at 11:50
  • What happens if you replace \left(\PTV[\TE[i]]\right) with \left(\PTV{\TE{i}}\right), i.e., if you replace the square brackets with curly braces?
    – Mico
    Feb 13, 2017 at 11:55
  • That does not resolve the problem as \TE[i] is no longer treated as the optional argument to \PTV.
    – Charlie
    Feb 13, 2017 at 21:58

2 Answers 2

5

Inside arguments, curly braces must be properly nested, lonely braces without partner are not allowed. However, this special treatment of braces do not apply for square brackets, there are just ordinary tokens for TeX. The use as optional argument is just a convention of LaTeX.

When TeX parses the optional argument of `\PIV':

\PTV[\TE[i]]

it looks for the first available closing bracket. It does not know about \TE and uses the closing bracket of its optional argument. The optional argument of \PTV is then:

\TE[i

That breaks the syntax for \TE.

The curly braces prevents this:

\PVI[{\TE[i]}]

Because the curly braces must match inside an argument, TeX cannot take the first closing square bracket inside the curly braces, and it uses the next closing square bracket, which happens to be the intended one.

The module xparse of LaTeX3 provides a more complicate parsing of optional arguments. To some degree, it simulates the special treatment of curly braces that they must be properly nested to the square brackets. The following example shows, that the curly braces can now be omitted. The macros with names ending in a are defined in the traditional way, the macros with names ending in b are defined via xparse:

\documentclass{article}
\usepackage{amsmath}

\usepackage{xargs}

\newcommandx\TEa[1][usedefault, addprefix=\global, 1=]{%
  \gamma\ifx\\#1\\\else_{#1}\fi
}
\newcommandx\PTVa[1][usedefault, addprefix=\global, 1=]{%
  \boldsymbol{\tau}\ifx\\#1\\\else_{#1}\fi
}

\usepackage{xparse}

\ExplSyntaxOn
\NewDocumentCommand{\TEb}{o}
{
  \gamma
  \IfValueT{#1}{\sb{#1}}
}
\NewDocumentCommand{\PTVb}{o}
{
  \boldsymbol{\tau}
  \IfValueT{#1}{\sb{#1}}
}
\ExplSyntaxOff

\begin{document}
$(\PTVa[{\TEa[i]}])$

$(\PTVb[{\TEb[i]}])$
\end{document}

Result

Remarks:

  • I added a simple test that suppresses the subscript if it is empty.
  • \sb is used instead of _, because the underscore is a normal letter with \ExplSyntaxOn. Then it can easily be used in macro names, but does not have the subscript meaning in math mode.
4
  • There's the experimental e argument, that lets you use a may be more natural syntax like (\PTV_{\TE_i}) while treating {\TE_i} and i as optional arguments (in case it's needed).
    – Manuel
    Feb 13, 2017 at 23:30
  • @Heiko, I think you misunderstand what I'm calling a bug - I've edited the post to clear up the ambiguity. We both agree that inserting the curly braces fixes the problem (and thanks to your post I now understand why). However, the issue is that Lyx when reopening the document doesn't keep them. Your code using ifx and the xargs package seems like it's a viable workaround, but without a explanation as to why, I don't think I can 'accept' this as is.
    – Charlie
    Feb 14, 2017 at 3:16
  • @Charlie I am not using Lyx, thus, I cannot say much about it. Package xargs is used to get a definition for \newcommandx, which is not a standard command. The stuff with \ifx is an addition to avoid empty subscripts. Defining the commands with \NewDocumentCommand of package xparse/LaTeX3 is the interesting part that should get you a workaround for the Lyx problem and saves you from typing the additional braces. Feb 14, 2017 at 6:03
  • Thanks @HeikoOberdiek, I have since confirmed with Lyx development team that it is a bug and a fix will be included in release 2.2.3.
    – Charlie
    Feb 14, 2017 at 6:25
2

Lyx development team have confirmed this is a bug. A fix has been developed and will be included in release 2.2.3.

2
  • Do you know which LyX tracker issue this is/was followed in? Mar 2, 2021 at 4:03
  • Unfortunately not, given it was such a long time ago.
    – Charlie
    Mar 11, 2021 at 10:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .