Rename recordUndoFullDocument to recordUndoFullBuffer.
Separate the notion of recording changes to paragraphs and recording changes in buffer parameters.
Audit every user of recordUndoFullDocument and replace it with either recordUndoBufferParams or recordUndoFullBuffer. Add comments to identify remaining work.
The problem was that the conversion to plain text (which is used as an
intermediate step) requires for some insets a valid buffer pointer, but
insets in the cut stack do not have one. Now we use the same temp buffer
business as for copying to the external clipboard.
Actually I wanted to do that in cc87f8100 but forgot to adjust the original
solution completely. Now we do not search for an arbitrary latexkeys instance
which just happens to have the same name as the macro, but we only use the
symbol that was explicitly set for global macros.
This patch fixes a series of warnings like:
{{{
In file included from ../../master/src/mathed/InsetMathBoldSymbol.cpp:13:
In file included from ../../master/src/mathed/InsetMathBoldSymbol.h:15:
../../master/src/mathed/InsetMathNest.h:37:7: warning: 'lyx::InsetMathNest::metrics' hides overloaded virtual function [-Woverloaded-virtual]
void metrics(MetricsInfo const & mi) const;
^
../../master/src/insets/Inset.h:186:15: note: hidden overloaded virtual function 'lyx::Inset::metrics' declared here: different number of parameters
(2 vs 1)
virtual void metrics(MetricsInfo & mi, Dimension & dim) const = 0;
^
}}}
For a description of the problem, see for example:
http://stackoverflow.com/questions/18515183/c-overloaded-virtual-function-warning-by-clang
3 different strategies have been used:
* in frontend, some functions have been renamed.
* in InsetMath.h, Inset::write has been explicitly imported too
* in InsetMathNest.h, since a comment said that hiding Inset::metrics is intended, a special trick has bee used to silence the warning.
Thanks to Enrico, who noticed that the previous fix did not take into account
the case of nonempty length argument + the next line beginning with [.
Now the parsing is exactly the inverse of InsetMathGrid::eolString().
There was an unsymmetry between reading and writing: InsetMathGrid::eolString()
adds curly braces if the first cell of the next line starts with [ to prevent
misparsing as optional argument of \\. These braces were not removed on reading.
This is different from bug #8999, since in this case a new macro instance is
created. You still get a TeX capacity exceeded error if you try to typeset the
exported document, but this is the same as for bug #8999 and better than a
crash.
Invoking a computer algebra system program for computing a selected
subformula has never worked (checked with all LyX versions back to 1.3)
and, moreover, in the presence of a selection things go awry.
This commit allows this computation by replacing the selected
subformula with the result of the computation.
There are 3 possible actions (in order)
* select current cell
* select all calls of inset
* select the inset from outside (in the containing inset)
This fixes completely #7727.
If there is only one row, a new line should not be appended. If
there is more than one row, the new line should not be appended for
the last row.
For example, if in LyX there was "as you can see in $x$ there..." a
copy/paste would lead to a newline after "x".
FileName::tempName() created a new temp file name by using qt to create a
temporary file with a unique name, and then deleting that file and returning
the name. This was unsafe, since other processes or even other threads of the
running LyX could create files with the same name between deletion and then
using the temp name.
This is fixed by using the TempFile class instead. As a side effect, a few
cases where the temp files were not deleted after usage were fixed as well.
The only place that is still unsafe is createTmpDir().
Thanks to maciejr we know now what the remaining problem was with bug 7954:
My unicode symbol fallback works fine, the problem was that a font named
"Symbol" is available on OS X, but it does not use the font-specific encoding
we expect: Almost all glyphs are at their unicode code point.
Therefore the bug is fixed by re-enabling the unicode workaround and blocking
the Symbol font on OS X.
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.
This is a follow-up of bug #8967. The implementation is self-explaining, the
only part which needs a comment is lyx2lyx: Since a 100% correct solution is
not possible, it has been decided not to switch amsmath off in the forward
conversion if no other ams command than \smash[t] and \smash[b] is used, but
to consider it a bug that older versions do not load amsmath automatically for
these commands. In the backward direction it is easy to keep the document
compilable, so just do that.
This method is a proxy for LyXRC::preview that forces to forward
declare some wrapper around an enum...
Instead, two simple static methods previewMath() and previewText() are
introduced, that make the code much easier to follow.
* remove unused class TexStream.
* remove unused virtual method Inset::cellXOffset
* remove second argument of FileDialog constructor, which was actually
not used
* remove some dead local code
* remove some unused private members of classes
* in InsetMathNest::updateBuffer, fix the logic of a test
This was a regression of e86cdc40: A newly introduced member variable was
not initialized in the constructor, which made it quite random whether symbols
like \coloneqq where displayed correctly or as an empty edit box.
This extends the already existing math symbol fallback mechanism in two ways:
1) When considering the availability of the math font, also take broken
code points into account. These are currently 0x0009 and 0x00ad, depending
on the platform.
2) If the fallback symbol in the standard "Symbol" font is not given, or if
the "Symbol" font is not available, or the fallback symbol is one of the
broken ones, try to use a generic unicode symbol as second fallback instead.
If this is available, we rely on Qt to find a font which has it. Only if
this is not available, display the symbol as ERT.
This ensures that we do never get a symbol which is not displayed: Either
it can be displayed, with or without fallback, or it will be shown as ERT.
The math parser aborts with an error message on \begin{align} and
\begin{align*} if this is not the hull inset. This is now fixed, however
this is not complete support for these two environments (the GUI does not
respect the numbering). It is only the minimal fix that ensures that no data
loss occurs for documents imported by tex2lyx.
This comes from trying to run tex2lyx on the AMS math test document
testmath.tex. Both \(...\) and \begin{math}...\end{math} are defined as
inline math formulas in standard LaTeX. tex2lyx recognizes this, but the
math parser in LyX did not handle "\begin_inset Formula \(" and
"\begin_inset Formula \begin{math}" correctly.
The fix is simple and safe: If we are in undecided mode (this is only true
for the first token of a math inset), create a hull inset of the respective
kind. Otherwise, handle the commands as before.
This avoids a message "Deco was not found. Programming error?" on stderr.
The added decorations are defined by amsmath, and equivalent to \vert (single
vertical bar) and \Vert (double vertical bar), respectively. They are used to
distinguish the single and paired versions (for use with \left and \right).
These symbols should cause amsmath to be loaded, but this would be too
dangerous to implement now.
Now interactive insertion of \smash[t] and \smash[b] is possible again.
\smash with optional argument behaves now exactly as in LyX 2.0.x, and without
optional argument it is supported by InsetMathPhantom.
When adding native support for \smash in 18779013 I overlooked that amsmath
redefines \smash to take an optional argument t or b. These optional
arguments are not parsed correctly anymore (bug 8967). This change fixes
the regression, so that \smash with optional argument appears in red, as it
was before th introduction of the native smash inset.
In the future, we should have native support for \smash[t] and \smash[b]
as well, but this would be a file format change (automatic amsmath loading),
and it is too late for 2.1.0.
When we export the file to latex, we use the redefinition_ variable to check whether we should output newcommand or renewcommand. This variable was set by the MathMacroTemplate::metrics() function, and this caused problem when the export is running in a different thread as the GUI.
In general, the metrics() functions should not change the Buffer; we have updateBuffer/updateMacros for that purpose.
Not all accessors did update the data previously. Therefore it could happen
that document export from the command line would output \newcommand, and from
GUI it would output \renewcommand for the same macro, simply because in the
GUI case the data was updated as a side effect of the GUI thread reading some
other member.
I also removed the mutable flag for requires_, since this member is always
set on construction and does not need any lazy update.
This is mostly unused private class members.
There are also a few unused functions that got #if'ed out. I never know in this case whether the code should be nuked.
False positive rate of hints is quite high. Although the includes can be
technically removed (due to other includes) they logically belong to the
header.
each failure.
There are several places I was not sure what to do. These are marked
by comments beginning "LASSERT:" so they can be found easily. At the
moment, they are at:
Author.cpp:105: // LASSERT: What should we do here?
Author.cpp:121: // LASSERT: What should we do here?
Buffer.cpp:4525: // LASSERT: Is it safe to continue here, or should we just return?
Cursor.cpp:345: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:403: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:1143: // LASSERT: There have been several bugs around this code, that seem
CursorSlice.cpp:83: // LASSERT: This should only ever be called from an InsetMath.
CursorSlice.cpp:92: // LASSERT: This should only ever be called from an InsetMath.
LayoutFile.cpp:303: // LASSERT: Why would this fail?
Text.cpp:995: // LASSERT: Is it safe to continue here?
As discussed on the list. No automatic contents detection is done, the user
needs to use the special paste menu instead. I used the new TempFile class
for safe temporary file handling.
The documentation would go into section 2.2 of UserGuide.lyx, but I am not
allowed to edit that document.
worth doing, as we were creating too much output for tooltips anyway.
But we need to ignore BibTeX insets altogether, as the collection of
the references, etc, is too slow.
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?
Somehow I overlooked that \sideset also supports nonscript arguments for
left and right. This is now fixed, although I do not like the toolbar names.
If somebody knows something better, please improve.
The toolbar image is the one Uwe attached to the bug report. Note that
\sideset works only for operators like \sum in the nucleus. LyX allows
any content, so you might get a LaTeX error. I don't know how to prevent
wrong content in the nucleus.
Some macros defined by wasysym.sty work only in text mode: They either
produce an error in math mode, or wrong output. These symbols are now marked
as text symbols, so that no \ensuremath is created for LaTeX export if they
appear inside \text{}, and the correct images are created.
