This commit takes into account also the case in which a prime follows
a superscript, a case not explicitly mentioned in bug 1633.
This case has to be accounted for in a different way. We cannot look
ahead when exporting, so we simply tell TeXMathStream to output an
empty group if we just output a superscript and a prime comes next.
If a macro has only optionals and none is specified and a [ immediately
follows, we have to terminate the macro with {}, otherwise what follows
is taken to be an optional argument.
Fixes#11665.
As evidenced in #11552, at loading time there is no way to tell
whether braces were added by LyX with certainty. However, after
[503f7db2/lyxgit], LyX does not automatically removes brace insets.
So, in case one faces the problems mentioned in [e8f480e7/lyxgit],
the workaround of adding a brace inset now will not be frustrated.
In essence, after [503f7db2/lyxgit], the real fix for #11552 would
have been reverting the part in [e8f480e7/lyxgit] that was adding
the braces on output.
When a macro with optionals appeared inside the optional argument of
another one, the onscreen display and latex output were wrong. This
issue was addressed at [e8f480e7/lyxgit] by enclosing in braces macros
with optional arguments. However, this was done even when the macro
with optionals was in a non-optional argument of another macro.
This commit limits the bracing to the cases where it is really needed
and allows to address some particular issues evidenced in #11552.
This is a long standing issue, present since the new math macros
inception in version 1.6. It manifests as a display issue when a
macro with optional arguments appears in the optional argument of
another macro. In this case the display is messed up and it is
difficult, if not impossible, changing the arguments as they do not
appear on screen as related to a specific macro instance. It also
manifests as latex errors when compiling, even if the latex output
is formally correct, due to limitations of the xargs package used
to output the macros. Most probably, both aspects have the same
root cause, as simply enclosing in braces the macro and its
parameters solves both issues. However, when reloading a document,
lyx strips the outer braces enclosing a macro argument, thus
frustrating this possible workaround.
This commit solves the display issue by correctly accounting for
macros with optional arguments nested in the argument of another
macro, and circumvents the xargs package limitations causing errors
by enclosing in braces the macros with optional arguments appearing
in the argument of an outer macro when they are output. This means
that when loading an old document with such macros and saving it
again, the macro representation is updated and will have these
additional braces. However, as such braces are stripped by lyx on
loading, there is no risk that they accumulate.
See also this thread:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg197828.html
It should be now possible underlining or striking out any kind
of math inset containing any math construct indigestible to ulem.
While this was already possible for inline math insets, they could
have break if an aligned environment was used, for example.
This is now possible also for diplay math. Even if this can be
nonsensical and not visually perfect, at least no latex errors
should be generated if one tries to.
Showing deleted display math by enabling "Show Changes in Output" was
only possible with dvi (through dvipost). Although LyX strikes out
such formulas on screen, it was impossible obtaining an output
directly using pdflatex (or other engines producing pdf) because
ulem cannot cope with display math material and gives errors.
The solution is to strike out by ourselves such deleted formulas.
I took into account several options. One of them would produce
an output similar to dvipost (which strikes out each element), but
would have required much more changes in the output routines.
Eventually, I opted for using tikz, which gives a more clean
output (as it requires to simply adding a preamble and a postamble
to the latex code of any displayed math, instead of a mark up
tailored to each particular math construct). The look of the pdf
output is similar to the way LyX strikes out the equations on screen.
Replace the manual manipulation of a stack of RowEntries with a Changer
function. When I introduced the stack of RowEntries, I did not know about the
Changer mechanism.
WriteStream is now built from an otexstream instead of an odocstream, and
therefore counts lines in a TexRow. Calls to TexRow are added in relevant places
in math insets.
This finishes adding line tracking for math in the source panel and for forward
search.
output routines. The idea is that in some cases people may not want to
use MathML, so we are going to try to give options.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33936 a592a061-630c-0410-9148-cb99ea01b6c8
suggestion. Now I wish I'd done XHTMLStream the same way....
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32691 a592a061-630c-0410-9148-cb99ea01b6c8
* MathStream{.cpp, h}:
- replace bool dryrun() by enum output that also knows whether the stream is for instant preview
* InsetMathHull.cpp:
- tell the stream whether we use it for instant preview.
* MathString.cpp (write):
- gracefully catch encoding exception for instant preview.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@30895 a592a061-630c-0410-9148-cb99ea01b6c8
