The strategy adopted in bc47054b had some drawbacks related to the way
instant preview snippets are generated. See the subthread starting at
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg187916.html
for details.
The strategy adopted in this commit is that of adding macro definitions
only for the macros actually used in a preview snippet, independently
of whether some macro was already used in a previous snippet. In this way
the snippets don't need to be changed according to whether they are
compiled as a whole or separately from each other. This fact was causing
the regeneration of a preview snippet whenever the cursor entered the
corresponding inset, even if the generated image would have not changed.
The problem of defining or redefining a macro is taken care by the
python scripts.
The math parser could not handle multicolumn grids. This is a problem because
there is no true ERT in math (everything is parsed).
Now multicolumn cells are parsed correctly. The display is also somewhat OK,
but apart from that any multicolumn related UI is missing. Since the file
format change is now done the UI can be added at any later point. The most
important part of bug 396 is now fixed: tex2lyx does not create invalid .lyx
files anymore for formulas containing \multicolumn.
I updated the tex2lyx test cases that produce correct output. tex2lyx does
still produce invalid output for the test cases which are not updated because
of the previous format change.
This is mainly needed to reduce the amount of ERT if you convert AMS example
documents with tex2lyx. No GUI support is needed, since \notag is equivalent
to \nonumber.
so we can write a limited amount when using this for TOC and
tooltip output.
This should solve the problem with slowness that Kornel noticed,
which was caused by our trying to write an entire plaintext
bibliography every time we updated the TOC. We did that because
he had a bibliography inside a branch, and we use plaintext for
creating the tooltip that goes with the branch list.
Other related bugs were fixed along the way. E.g., it turns out
that, if someone had an InsetInclude inside a branch, then we would
have been writing a *plaintext file* for that inset every time we
updated the TOC. I wonder if some of the other reports of slowness
we have received might be due to this kind of issue?
of things like:
pit.push_back(CursorSlice(*this));
which I've had to change to:
pit.push_back(CursorSlice(const_cast<InsetCaption &>(*this)));
and similarly in a few other places.
If anyone thinks we should instead have:
explicit CursorSlice(Inset const &);
then we can also do that.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37192 a592a061-630c-0410-9148-cb99ea01b6c8
then output \setcounter macros during snippet generation, so that we get
the right equation values.
Note: It would be possible to use this same machinery to fix bugs in
instant preview, e.g., that you always get things like (0.3) as equation
numbers, if you use equations numbered by section. I'll perhaps post a
patch for that.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37186 a592a061-630c-0410-9148-cb99ea01b6c8
still be a mess in many cases, but hopefully we won't have to go here
very often.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37181 a592a061-630c-0410-9148-cb99ea01b6c8
numbering in XHTML output, but it's just as easy to fix this in the LyX
display.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37177 a592a061-630c-0410-9148-cb99ea01b6c8
that also makes sure it doesn't do more work than it needs to do, by
limiting the size to 40 characters. Previously, InsetBranch::addToToc()
would have added a string representing the entire contents of the
branch! It's hard to imagine that having to recalculate that sort of
thing doesn't cause some problems with speed, especially in documents
with lots of notes and branches and such.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36974 a592a061-630c-0410-9148-cb99ea01b6c8
I'll try to figure out how to get rid of the magic booleans.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35022 a592a061-630c-0410-9148-cb99ea01b6c8
allow this as a fallback. E.g., if we're unable to export as MathML,
then we try to export as an image.
There are several ways, I am sure, in which this implementation is not
ideal.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34993 a592a061-630c-0410-9148-cb99ea01b6c8
This patch essentially reverts r30795 and also provides the correct fix
for #2969.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34751 a592a061-630c-0410-9148-cb99ea01b6c8
For a displayed equation, the height is artificially increased by a displayMargin() in InsetMathHull::metrics if it is a displayed equation and there is a preview.
This extra height is not covered by the preview image and what one can see is the background as drawn by the MathHull inset. The color of this background should be either Color_mathbg or Color_background depending on whether the preview is shown or not.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32560 a592a061-630c-0410-9148-cb99ea01b6c8
as to allow us to call the routine when we are preparing for output and
so to do certain things we might not want to do every time.
This is an abuse of updateLabels(), in a way, but updateLabels() long
ago became the general recurse-through-the-Buffer routine, and to
implement the sort of thing I want to do here in validate(), say, much
of the code in updateLabels()---in particular, the counter-update
code---would have to be duplicated. So I believe this is the best, and
easiest, way to go.
Actual use of the new argument will follow.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32318 a592a061-630c-0410-9148-cb99ea01b6c8
Turns out MathML is already here, for the most part, so this will
not be too bad at all.
Anyone else think that is very cool?!
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31979 a592a061-630c-0410-9148-cb99ea01b6c8
Math manual loads and save correctly it seems but expect some instability period.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31898 a592a061-630c-0410-9148-cb99ea01b6c8
This patch initializes the buffer_ member of a MathHull inset in most
(but not all) cases. The problems with buffer_ should be greatly
allievated now, but there still can be some corner case.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31873 a592a061-630c-0410-9148-cb99ea01b6c8
This reverts part of r10553. There, an extra '//' was added when the last line was empty. However, this really makes an extra line and that is visible when the lines have a line number. The bug #2067 that would have been fixed by this does not seem to 'exist' anymore.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@30795 a592a061-630c-0410-9148-cb99ea01b6c8
