Using math mode within mbox mismatches $

[bburghgr]

If I have a line of text that uses math mode via pairs of $$, and an \mbox within that block, which contains its own $$ math mode block within the \mbox, then latexdiff's parsing seems to match the opening $ outside of the \mbox with the opening $ within the \mbox.

I'm not sure if there's an easy workaround, but if there is then I didn't manage to find it (I ended up removing the entire \mbox and using \text to make the diff work for my immediate use case, but that's kind of a tedious process).

What I ran:

$ latexdiff --version
This is LATEXDIFF 1.3.5a (Algorithm::Diff 1.201, Perl v5.38.2)
  (c) 2004-2024 F J Tilmann

$ cat 1.tex 
\documentclass{article}
\usepackage[utf8]{inputenc}
\begin{document}
$1 \mbox{$a$}$
\end{document}

$ cat 2.tex 
\documentclass{article}
\usepackage[utf8]{inputenc}
\begin{document}
$2 \mbox{$a$}$
\end{document}

$ latexdiff 1.tex 2.tex > diff.tex

What I expected:

[...]
\begin{document}
\DIFdelbegin \DIFdel{$1 \mbox{$a$}$}\DIFdelend \DIFaddbegin \DIFadd{$2 \mbox{$a$}$}\DIFaddend
\end{document}

What I got:

[...]
\begin{document}
\DIFdelbegin \DIFdel{$1 \mbox{$}\DIFdelend \DIFaddbegin \DIFadd{$2 \mbox{$}\DIFaddend a$}$
\end{document}

This leads to the error:

Runaway argument?
{$1 \mbox {$}\DIFdelend \DIFaddbegin \DIFadd {$2 \mbox {$}\DIFaddend \ETC.
! File ended while scanning use of \DIFdel.
<inserted text> 
                \par 
<*> diff.tex
            
? 

[ftilmann]

As you suspected this is an edge case that will be rather tricky to fix.
A possible work-around is to change either the inner or the outer $..$ pair to (...) in both the new and old file, which gives the expected behaviour. You can also use \begin{math}...\end{math} for the outer pair, which will then let latexdiff peek into the math expression and only mark the "1" as deleted and "2" as added, rather than the whole expression.

In case you cannot change the old file you can use a functionality added a few weeks ago (not yet in a release version):
By adding special comments as here

%BEGIN DIFNOMARKUP
$2 \mbox{$a$}$
%END DIFNOMARKUP

in the new file you can suppress the markup inside the enclosed region. This means, the resulting output should be at least compilable but changes in the equation will not be shown.

[ftilmann]

I assigned "Low" priority to a fix as it would be relatively complicated for what I feel is a niche case, and it can be avoided by also using the other options for marking inline maths. (I did not test but if you change both inner and outer symbols you might get into trouble again.

[bburghgr]

Thanks! Agreed that this is a niche case and can reasonably be considered low priority. The \begin{math}...\end{math} workaround is probably the best approach for my production use case, so thanks for the suggestion.

I haven't tested it with the development version, but I should mention that applying DIFNOMARKUP in the usual way (to both the old and new file) did not have the intended effect in the real world example where this was encountered. I actually ran into it with a $$ math mode inside of an \mbox in an array inside of $$ math mode in the cell of a table, and something about that combination seemed to trick the version of latexdiff (1.3.2) in my working environment into trying to diff the table despite the DIFNOMARKUP block, leading to the nested math mode issue.

It's may be a low priority for me, but if I manage to come up with a minimal example that reproduces the DIFNOMARKUP behavior with the development version, then I'll open a separate issue for that.

[ftilmann]

I was referring to a new way of marking a block where markup should be suppressed, which has only been introduced recently, which uses special comments (%BEGIN DIFNOMARKUP and %END DIFNOMARKUP ) to prevent markup being applied in the first place.
The 'old' (and still possible) way using \begin{DIFNOMARKUP} and \end{DIFNOMARKUP} works by removing the applied markup in postprocessing, which might be less robust. In any case the bug report would still be of interest, although anything with nested $$ is going to be troublesome.