amsmath: things enclosed by brackets in the new line after `\begin{aligned}` disappear in the output about latex2e

[FrankMittelbach]

nice example of the issue. The reason for the extra t is fairly clear (but also shows that there is a need to do something about it). What happens is that that the code does a simple test (assuming that the option argument is a single char), namely \if #1t\vtop \else \if #1b \vbox \else \vcenter \fi.

so if you have a single char inside the optional argument it will not be matched, so you get \vcenter
but with \mathbf{k} as #1 ends up being true as that gets expanded (followed by a t so the t prints. It could get worse :-)

So yes we need to address this but not in a rush during this week, that is too dangerous.

[davidcarlisle]

On 27 December 2017 at 03:52, Yunyang Liu ***@***.***> wrote: Brief outline of the bug If a new line after \begin{aligned} begins with a left bracket, anything before next occurrence of right bracket (along with the brackets themselves) will disappear in the output pdf. Minimal example showing the bug \RequirePackage{latexbug} \documentclass{article}\usepackage{amsmath} \begin{document} \begin{equation} \begin{aligned} [p, q] = 1 - 1 = 0 \\ [q, p] = 1 - 1 = 0 \end{aligned} \end{equation}\end{document} Log (and possibly PDF) file vanishing_brackets.pdf <https://github.com/latex3/latex2e/files/1588279/vanishing_brackets.pdf> vanishing_brackets.log <https://github.com/latex3/latex2e/files/1588280/vanishing_brackets.log> Possible cause I checked amsmath's documentation <http://mirrors.ctan.org/macros/latex/required/amsmath/amsmath.pdf> and noticed that The aligned environment takes an optional argument that indicates its vertical position in relation to surrounding material: t, c, or b for top, center, or bottom. Therefore the behavior above might be caused by [p, q] (which is part of the math formula being typesetted) being recognized as the optional argument. This should be considered as a bug, as it does not meet the principle of least astonishment <https://en.wikipedia.org/wiki/Principle_of_least_astonishment>. My temporary workaround I insert a \relax or {} before the first left bracket, and the brackets stuff is no longer recognized as the optional argument. Thank you for your interest.

This is in fact the normal behaviour of optional arguments in latex, you will see the same thing in a standard `array` environment in the first cell of any row, where a [ will be taken as an optional argument of the \\ ending the previous row. That said, it is perhaps surprising that it occurs here in amsmath as in most places amsmath uses its version \new@ifnextchar rather than \@ifnextchar: a version of the lookahead for [ that does not skip over white space. However at the start of aligned and related environments it uses the standard \@ifnextchar It isn't clear that it is possible to change this after all this time, certainly using \new@ifnextchar (which allows space as well as newline to stop the lookahead) would mean that \begin{aligned} [t] x &=... would typeset [t] rather than being top aligned so such a change could change existing documents with no warning. It might be possible to have a package option controlling this though. David

Thanks for the reply.

I would certainly prefer the new macro, but the altering of existing documents is also a big issue. So maybe it is possible to change in a way that retains current behavior, but displays a warning if [ does not immediately follow.

And, if that would take too much work (I have no idea about its difficulty), displaying a warning when the received argument is not among t, c, & b will also help unexperienced users like me a lot. Practically this will cover most cases as well, only leaving out the unlucky ones whose formula start with [t] or so.

[muzimuzhi]

(might be off topic)

A pair of package options named allowspaces and disallowspaces (default), provided by package mathtools, does the job @davidcarlisle suggests. Maybe it can be used as a workaround.

[davidcarlisle]

@muzimuzhi yes thanks, more generally there are some vague plans to merge parts or all of mathtools in to amsmath perhaps, one day. certainly the parts of mathtools that are "fixes" to amsmath rather than clearly extensions.

[FrankMittelbach]

Am 27.12.17 um 11:53 schrieb David Carlisle:

It isn't clear that it is possible to change this after all this time, certainly using ***@***.*** (which allows space as well as newline to stop the lookahead) would mean that \begin{aligned} [t] x &=... would typeset [t] rather than being top aligned so such a change could change existing documents with no warning. It might be possible to have a package option controlling this though.

wouldn't it be possible/better to make sure that the content of the optional argument received makes sense? Ie if the value is not one of the expected ones that actually have an action attached then either bring it back or at least generate an error. The fact that the output vanishes probably means it is simply \csname ... \endcsname inside resulting in \relax which one could test for --- haven't checked the implementation

[davidcarlisle]

Something like this, perhaps (@FrankMittelbach )?

 \documentclass{article}
\usepackage{amsmath} 


\makeatletter

\def\ams@t{t}\def\ams@b{b}\def\ams@c{c}
\renewcommand{\start@aligned}[2]{%
    \RIfM@\else
        \nonmatherr@{\begin{\@currenvir}}%
    \fi
    \savecolumn@ % Assumption: called inside a group
    \alignedspace@left
\def\ams@tmp{#1}%
\let\ams@tmpb\@empty
\ifx\ams@tmp\ams@t\vtop\else
\ifx\ams@tmp\ams@b\vbox\else
\ifx\ams@tmp\ams@c\else
    \def\ams@tmpb{[#1]}%
\fi
\vcenter
\fi\fi
        \bgroup
        \maxfields@#2\relax
        \ifnum\maxfields@>\m@ne
            \multiply\maxfields@\tw@
            \let\math@cr@@@\math@cr@@@alignedat
            \alignsep@\z@skip
        \else
            \let\math@cr@@@\math@cr@@@aligned
            \alignsep@\minalignsep
        \fi
        \Let@ \chardef\dspbrk@context\@ne
        \default@tag
        \spread@equation % no-op if already called
        \global\column@\z@
        \ialign\bgroup
           &\column@plus
            \hfil
            \strut@
            $\m@th\displaystyle{##}$%
            \tabskip\z@skip
           &\column@plus
            $\m@th\displaystyle{{}##}$%
            \hfil
            \tabskip\alignsep@
            \crcr
\ams@tmpb
}
\makeatother

\begin{document} 
\begin{equation}
1=\begin{aligned}
[p, q] = 1 - 1 = 0 \\
[q, p] = 1 - 1 = 0
\end{aligned}
\end{equation}
\begin{equation}
2=\begin{aligned}[t]
[p, q] = 1 - 1 = 0 \\
[q, p] = 1 - 1 = 0
\end{aligned}
\end{equation}
\begin{equation}
3=\begin{aligned}[b]
[p, q] = 1 - 1 = 0 \\
[q, p] = 1 - 1 = 0
\end{aligned}
\end{equation}
\begin{equation}
4=\begin{aligned}[c]
[p, q] = 1 - 1 = 0 \\
[q, p] = 1 - 1 = 0
\end{aligned}
\end{equation}

\end{document}

[eg9]

On 30 Mar 2018, at 23:59 , Frank Mittelbach ***@***.***> wrote: Am 27.12.17 um 11:53 schrieb David Carlisle: > It isn't clear that it is possible to change this after all this time, > certainly using ***@***.*** (which allows space as well as newline to > stop the lookahead) would mean that > > \begin{aligned} [t] > x &=... > > would typeset [t] rather than being top aligned so such a change could > change existing documents with no warning. > It might be possible to have a package option controlling this though. wouldn't it be possible/better to make sure that the content of the optional argument received makes sense? Ie if the value is not one of the expected ones that actually have an action attached then either bring it back or at least generate an error. The fact that the output vanishes probably means it is simply \csname ... \endcsname inside resulting in \relax which one could test for --- haven't checked the implementation

What if a user wants to typeset [t]? \begin{aligned} [t]&=x\\ *x&=y \end{aligned} Ciao Enrico

[davidcarlisle]

well then it works as now, they need `\relax` or something. It would be possible to use the ams non space skipping version of \@ifnextchar so your example of [t] on the ext line typeset but then existing documents using [t] to get top alignment would change. while the suggestion in the comment would also change existing document, only in the case that they were getting the argument silently dropped (if it didn't begin with t or b) or typeset without the leading t or b if it was something like [boom] No solution is issue-free I fear

…

On 1 April 2018 at 21:51, Enrico Gregorio ***@***.***> wrote: > On 30 Mar 2018, at 23:59 , Frank Mittelbach ***@***.***> wrote: > > Am 27.12.17 um 11:53 schrieb David Carlisle: > > It isn't clear that it is possible to change this after all this time, > > certainly using ***@***.*** (which allows space as well as newline to > > stop the lookahead) would mean that > > > > \begin{aligned} [t] > > x &=... > > > > would typeset [t] rather than being top aligned so such a change could > > change existing documents with no warning. > > It might be possible to have a package option controlling this though. > > wouldn't it be possible/better to make sure that the content of the > optional argument received makes sense? > > Ie if the value is not one of the expected ones that actually have an > action attached then either bring it back or at least generate an error. > > The fact that the output vanishes probably means it is simply \csname > ... \endcsname inside resulting in \relax which one could test for --- > haven't checked the implementation What if a user wants to typeset [t]? \begin{aligned} [t]&=x\\ *x&=y \end{aligned} Ciao Enrico — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNcAssSPftO3xekxyN08QzVNObgdbhWks5tkT3ogaJpZM4RNJxz> .

[davidcarlisle]

note the version in the comment above treats [] as not an option so would typeset [] it may be better to treat it as a valid option, acting like [c] as many editors seem to generate empty options (not necessarily for aligned, but in general) you often see \begin{table}[] for example.

[car222222]

Just a note on the use of: \ams@tmpb
At first I thought it looked very unsafe.
But on retreading (oops!) the code I now
see that it is ‘very’ local!
Extra precaution (since the
escape of such temporary defs
is a common cause of bugs)
would be to make it empty again
after using it.

[car222222]

I can see how empty optional May well happen due to smart editors not being clever enough to know that if a use does not actively edit the template then it should remove the delimiters.

So probably a good idea to interpret empty as c.

But this raises the question of what to do for all other empty optionals?? In all of latex.

[FrankMittelbach]

@davidcarlisle yes that is more or less what I was thinking of: doing something less surprising when the optional argument doesn't fit the spec. and yes, I think accepting an empty default in this case is probably a sensible idea too.

[FrankMittelbach]

@car222222 I may be mistakenbut most if not all of LaTeX actually already supports the use of "empty" meaning the default action whenever the optional value is a of a defined set, e.g. \begin[]{tabular} = \begin[c]{tabular} and the like. Probably needs some verification of that claim but I think it is largely true in core (there aren't that many)

[davidcarlisle]

On 2 April 2018 at 01:07, Chris Rowley ***@***.***> wrote: I can see how empty optional May well happen due to smart editors not being clever enough to know that if a use does not actively edit the template then it should remove the delimiters. So probably a good idea to interpret empty as c. But this raises the question of what to do for all other empty optionals?? In all of latex. I haven't checked them all but in most cases they either work as the

default or give an error people seem to expect that \begin{table}[] "just works" without realising that it only works as the code has special case to make it not mean "don't allow this table anywhere":-) the amsmath case though "anything other than t or b working as c means that things get silently discarded, and options starting with t or b but have following text act weirdly as it just does `\if t #1...

[blefloch]

Possible worry: before, \begin{aligned}["something expanding to t or b or c"] would work; with the new code David suggested, it will not. This may very well be a problem as some package/class author may have very well stored the alignment into a macro. It might make sense to "f-expand" because we're in math mode (spaces don't matter) and going to typeset things anyways (expandable stuff at the start mostly doesn't matter).

[davidcarlisle]

yes I had wondered about using edef but didn't dare. I suppose f expansion would be safer, either way I think there are too many issues (including coordination with mathtools) so I don't plan changing this this week so will miss the texlive 2018 initial release.

[FrankMittelbach]

sounds like a sensible plan. This isn't urgent

[Abacn]

Hi everyone, I also found the problem and the working example might provide some evidence. In a particular case a mysterious "t" will appear:

Minimal Working Example:
`
\RequirePackage{latexbug} % <--should be always the first line (see CONTRIBUTING)!
\documentclass{article}
\usepackage{amsmath}
\begin{document}
\author{}
\title{}
\maketitle
\begin{equation}
[\mathbf{K}]=1
\end{equation}

\begin{equation}
\begin{aligned}
[\mathbf{K}]=1
\end{aligned}
\end{equation}

\end{document}
`

Interestingly, the second equation produces "\mathbf{K}t=1" with a redundant "t". If the first equation is absent, or "\mathbf" is not specified in either equation, the second one will produce "=1" as is already pointed.

[FrankMittelbach]

really think we should make at least sure that only c/b/t are accepted as optional argument the fact that the optional arg can start on a new line is something we can't rally change in core amsmath because it is too long ot there but dropping a bracket group is clearly an unintended bug and so is the fact that [aa] will be interpreted as top and the group dropped.