In the test case the crash occured in mathml export of the temporary buffer,
because the macro was updated, and because one of the used other macros was
not copied, the macro argument was detached. However, the underlying problem
of the crash was a broken ArgumentProxy::mathMacro_ reference which became
invalid each time the ownng MathMacro was copied. In the bug test case the
copying happened due to resizing a std::vector, but any other copy would have
created the same problem. The crash did not always happen, because sometimes
the old freed memory was not immediately reused, so the invalid reference did
still point to usable data.
The fix is easy: Convert ArgumentProxy::mathMacro_ to a pointer and update it
always after creating a copy of the owner. The pimpl of MathMacro from the
previous commit helps here to distinguish between the data that can be
automatically copied (in MathMacro::Private) and the cleanup that needs to be
done manually (in MathMacro). This way, the manual copy constructor and
assigment operator of MathMacro does not need to be touched if a new member is
added.
The expanded cells of a mathmacro were previously stored in an InsetMathSqrt.
This was only used as a container for the MathData object in the first cell
of the sqrt inset, which contained the actual expanded arguments.
Funny enough, the only place were the inset property of expanded_ was really
used cannot be seen in the diff. It was MathMacro::kerning(), and this usage
was wrong, since InsetMathSqrt::kerning() always returns 0. Threfore, using
the correct type (MathData) for expanded_ does not only make the code more
readable, gets rid of an unneeded dependency, but also fixes a bug: Now the
correct kerning is returned for expanded cells. Also, expanded_ and
definition_ use the same type now, which looks nicely symmetric.
Previously, things like [ name ] where exported for computer algebra systems.
Now, the expanded macros are exported, which may still be wrong, but now the
CAS has at least a chance to understand what was meant.
The computation of length on screen depend in particular of the computation of the size of an em. Many places of the code used to rely on the width of the M character, which is not really correct:
http://en.wikipedia.org/wiki/Em_%28typography%29
In digital typography, the best value to use is the point size of the font.
* Implement FontMetrics::em(), which returns the value in pixels of the EM unit.
Convert code to use it.
* Introduce Length::inPixel(MetricsBase const &), which takes the textwidth and em information from the MetricsBase object. Convert code to use it.
* Fix several places where Length::inPixel is used without a proper em value.
* add mathed_font_em() helper function. It should eventually be removed like some other functions in MathSupport.
* Add dummy implementation of FontMetrics to tex2lyx for linking purposes.
LyX did not display the limits of the big math operators defined by
stmaryrd.sty correctly. The reason for this was a missing check in
InsetMathSymbol::metrics(), where it is hardcoded which symbols use display
style limits and which symbols use inline limits. In an ideal world this
information would be contained explicitly in lib/symbols.
This should go to branch as well.
We have some math macros that exist only because LyX can display them easily,
but which require user preamble code. These commands should not appear in
autocompletion, they are only there to make the formulas of users who actually
need thgese symbols and know what to put into the preamble more beautiful.
This avoids invoking the insert space dialog instead of the math version. Thereafter, spaces are correctly inserted inside macro templates.
This is the last part of the fix to #9432.
Thanks to Scott for testing. If a macro is unknown (displayed in red), then
macro_ is 0. The LATTEST is now adjusted and works like in MathMacro::write()
where I stole it from.
The math icons for the symbol image in the math completer were hardcoded to the
command names. This is wrong for some icons for various reasons, e.g. the case
insensitivity of windows file systems. Therefore we have to use the replacement
list which is also used for the toolbar icons. Bug #3538 is not closed because
of this problem, but IMHO it has nothing to do with this bug, it is a more
general one.
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.
Actually, the test case showed several problems:
- ERT insets did use layout "Standard", not "Plain Layout"
- The font scale was read correctly, but tex2lyx claimed that it did ignore
the option "scaled=0.95"
- If a third argument of the CJK environment was given, it caused the whole
environment to be put in ERT with a broken encoding. This is now fixed for
the bug test case by using the \font_cjk header variable, but the encoding
problem still exists for unsupported encodings. I'll file a separate bug
for that.
- The CJKutf8 package was not handled in the preamble parsing. Therefore the
chinese comment in the preamble was read with a wrong encoding, and guessing
the document language did not work.
The new file CJKutf8.tex was created by copying and modifying CJK.tex, but
unfortunately it is impossible to tell git to inherit the history of CJK.tex
for the new file (search the web for git svn copy if you want to know details).
The fix is basically mechanical, the additional code for fraction like insets
with three arguments was stolen from \unitfrac. As any math package,
stackrel.sty needs a buffer parameter to switch it off.
I also added the two stackrel flavours to the toolbar.
stmaryrd.sty sets these symbols up as variable size math delimiters (i.e.
they may be used with \left and \right). Now LyX knows about that and offers
them in the delimiter dialog as well as single symbols.
The stmaryrd package adds support for lots of math symbols, using a font
designed to accompany the computer modern fonts. The changes in detail:
- Fix generate_symbols_list.py to work with stmaryrd.sty. It loooks like it
was automatically translated from a perl version and never used.
- Generate the new symbols in lib/symbols using generate_symbols_list.py and
add some manual adjustments
- Generate stmary10.ttf by a simple ttf export from stmary10.sfd with fontforge
- Add license info for stmary10.ttf
- Create a test file with all symbols from stmaryrd.sty. Actually it would be
nice to have this for the other fonts as well.
- The mechanics: lyx2lyx, tex2lyx, font machinery etc.
This patch puts all projects into subfolders (at least for MSVS). In this
way, there is a better overview (especially if the number of test projects
will be increasing).
The mhchem package treats the caret both as a shorthand for \uparrow or
as a superscript operator according to whether it is surrounded by
spaces or not. The \ce and \cf insets allow inserting spaces but there
is no provision for inserting a space after the caret, which is always
considered by LyX as a superscript operator. The solution here is to
insert a space after the caret if the superscript is empty or an empty
brace inset.
Mathed does not allow empty superscripts, so an empty brace has to be
inserted when working in LyX. On the other hand, when importing latex
code, an empty superscript is retained.
This has no effect whatsoever for normal latex code, as a space after
the caret is ignored. In any case, the output is only changed if an
empty brace inset is used as superscript. Specifically, the output is
changed from "^{{}}" to "^ {}".
While cppcheck did not turn out any suspicious error messages, using
the "performance" flag highlighted several nitpicks in three categories
* do not use it++ for iterators, ++it is better
* do not use size() to test for emptyness, empty() is here
* do not use "const T" as a function parameter, "const & T" is better
I doubt that any of these is a real performance problem, but the code is cleaner anyway.
This is not needed, since LyX supports comments in math. Data loss with math
comments containing a backslash in LyX has been fixed as well.
The test case was found in bug #8104.
When using, e.g., a 'mathcal' inset in math, the inline completion and
other special characters like '\#', '{..}' are are painted in the
'mathcal' font as well. This is overcome by setting the mathnormal font
before painted these characters.
If the stream is good (i.e. there are still tokens) and we expect an
argument, we call getArg(). However, if there are only spaces, the stream
suddenly isn't good anymore after 'skipSpaces' and we would get an error
when calling 'getChar'. Therefore we have to check whether the stream is
still good.
If the stream is not good, we don't need to 'putback', because we didn't
read anything yet. If we now do rewind the stream, we are asking for
problems as in bug #8089.
This was introduced in [3cafb856\lyxgit] to fix bug #4318.
* Avoid undo step when using backspace in macro mode
* Use recordUndoInset when entering macro mode (if one enters something like \hline, the outer inset itself will be modified)
* Use recordUndoInset when pasting in an INsetMathGrid (same reason as above)
Math commands need it as well as text commands. At the same time, this
further unifies the checking for termination and fixes cases of wrong
output (e.g. for 0x2005).
If \hline is entered, do not create an unknown inset, but increase the number
of hlines of the current row if that is allowed. The same idea is applied to
copy-paste (not part of the bug report).
This is also a test for committing via git.
changing limits status (fixes bug #8007)
* InsetMathScript::getStatus (new) : handle properly status for LFUN_MATH_LIMITS here, along with checkmark support for the menu)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40700 a592a061-630c-0410-9148-cb99ea01b6c8
The small ascii art in InsetMathCancel::draw has line continuation characters at
eol, this make consecutive lines be andled as one. The use of a block comment
instead of single line comments makes this less of a "problem." Also it removes
a warning with gcc 4.7.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40699 a592a061-630c-0410-9148-cb99ea01b6c8
Internal machinery, no file format change and no UI change yet
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40562 a592a061-630c-0410-9148-cb99ea01b6c8
now) and move more packages to the new exclude mechanism.
The remaining ones are not so easy.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40442 a592a061-630c-0410-9148-cb99ea01b6c8
and menus. The newline we were writing previously caused all kinds
of problems. Writing a whole array in some cases would also cause
problems. So we do less.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39971 a592a061-630c-0410-9148-cb99ea01b6c8
- Interpret argument of LFUN_SPACE_INSERT correctly
- Use InsetMathSpace instead of InsetMathSpecialChar for "\ " (bug # 7728)
- Use InsetMathSpace instead of InsetMathChar for ~ (bug # 7728).
This fixes also the display in LyX (previously a literal ~ was displayed).
Using InsetMathSpace enables also the "Insert Formatting" menu entries.
No file format change is needed, since the LaTeX export is unchanged.
Note that there are still some bugs related to spaces in math:
#7746, #7747, #7749, #7842
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39947 a592a061-630c-0410-9148-cb99ea01b6c8
Now you can also require a|b|c, and if any of the features is already used,
no other one will be loaded. The first feature wins if none is already used.
This is required for a part of bug #7811.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39884 a592a061-630c-0410-9148-cb99ea01b6c8
- \negmedspace and \negthickspace outside of math
- \enspace, \hspace*, \hspace*{\fill} and \hfill inside math
(fileformat change)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39557 a592a061-630c-0410-9148-cb99ea01b6c8
Corresponding test-case needed a fix as well and now it is passed.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39518 a592a061-630c-0410-9148-cb99ea01b6c8
I don't think we need to record anything yet, since we are not changing
anything here. The dialog will call a new LFUN to do the change.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39253 a592a061-630c-0410-9148-cb99ea01b6c8
* uniqueLabel(docstring & label) to enforce label unicity
* updateLabel() to update only the label.
* InsetLabel::updateLabelAndRefs() to update label & refs
* InsetLabel::updateReferences() to update the references
This fixes bug #7655
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39250 a592a061-630c-0410-9148-cb99ea01b6c8
Added corresponding regression tests findadv-re-01 and -02 for finding these special characters.
Unfortunately, braces {} are a little bit special and don't work yet. Added findadv-re-03 regression test to not forget about this case.
This goes along the line of fixing issues reported by Andrew Parsloe and summarised as #7638.
Last note: Still there will be cases when the Advanced F&R won't work, especially if the text to be found and/or the search pattern is preceded by backslashes or others.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39135 a592a061-630c-0410-9148-cb99ea01b6c8
This is needed when instant preview is on,
so we avoid the empty preview due to latex compilation error.
Fixing issue 1. reported at: http://permalink.gmane.org/gmane.editors.lyx.devel/136992.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39015 a592a061-630c-0410-9148-cb99ea01b6c8
by Jan Paul Imhoff. The problem was that we were assuming (as we still
do in some places) that there are always at least two cells.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38717 a592a061-630c-0410-9148-cb99ea01b6c8
multicell inset, where we now export all of the cells
separated by "\t", instead of only the first cell.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38712 a592a061-630c-0410-9148-cb99ea01b6c8
assure to switch to math mode if needed. This helps avoiding latex
errors (see http://thread.gmane.org/gmane.editors.lyx.general/69580)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38579 a592a061-630c-0410-9148-cb99ea01b6c8
as an image.
The math macro now exports as XHTML + MathML and can be viewed in
Firefox.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38190 a592a061-630c-0410-9148-cb99ea01b6c8
preparatory to fixing #7080. Note that mathed uses the same routine, but
for a completely different purpose, so I did not rename it there. I have
seen no difference in behavior after testing, e.g., opening and
exporting Math.lyx, and also re-saving it and looking at the diff.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38109 a592a061-630c-0410-9148-cb99ea01b6c8
Two things have been fixed here:
1) the selection should not be cleared when the user right clicks a math inset that is part of the selection,
2) the type of context menu should be determined at mouse-press, because that is the moment when the cursor is set. However, we should do it after setting the cursor, because setting the cursor might change the selection status and this influences the choice for the type of context menu.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37961 a592a061-630c-0410-9148-cb99ea01b6c8
Currently, if an inset outputs a newline, the new latex row is still
associated with a previous id/pos. Now, if a latex error occurs before
this newline, we would still highlight everything associated to that
id/pos, even if it is extraneous to the error.
This is avoided by associating the new latex row with the id/pos in
effect right before entering the inset. If an inset does not output
a newline, it is not excluded from the selection, consistent with the
fact that the text of the inset does appear in the error description.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37903 a592a061-630c-0410-9148-cb99ea01b6c8
resetFontEdit(). The former is used for on-screen and export formatting,
and the latter is used for interactive editing.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37761 a592a061-630c-0410-9148-cb99ea01b6c8
counting when exporting to latex. This is done for the code comprised
between \begin{document} and \end{document}, while the preamble code
still needs manual calls to TexRow::newline() for registering new lines.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37584 a592a061-630c-0410-9148-cb99ea01b6c8
blank lines may be inadvertently output. This is achieved by using two
special iomanip-like variables (breakln and safebreakln) in the lyx::
namespace. When they are inserted in the stream, a newline is output
only if not already at the beginning of a line. The difference between
breakln and safebreakln is that, if needed, the former outputs '\n'
and the latter "%\n".
In future, the new class will also be used for counting the number of
newlines issued. Even if the infractrure for doing that is already in
place, the counting is essentially still done the old way.
There are still places in the code where the functionality of the
class could be used, most probably. ATM, it is used for InsetTabular,
InsetListings, InsetFloat, and InsetText.
The Comment and GreyedOut insets required a special treatment and a
new InsetLayout parameter (Display) has been introduced. The default
for Display is "true", meaning that the corresponding latex
environment is of "display" type, i.e., it stands on its own, whereas
"false" means that the contents appear inline with the text. The
latter is the case for both Comment and GreyedOut insets.
Mostly, the only visible effects on latex exports should be the
disappearing of some redundant % chars and the appearing/disappearing
of null {} latex groups after a comment or lyxgreyedout environments
(they are related to the presence or absence of a space immediately
after those environments), as well as the fact that math environments
are now started on their own lines.
As a last thing, only the latex code between \begin{document} and
\end{document} goes through the new class, the preamble being directly
output through odocstream, as usual.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37360 a592a061-630c-0410-9148-cb99ea01b6c8
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
Using updateMacros() entails a performance hit when loading a document
with really a lot of macros. So, revert to the original strategy of
tracking macros at creation time. In order to also account for macros
defined in a child document, the child is now loaded by the include inset
at construction time instead of after the master has finished loading.
This strategy mimics what updateMacros() was accomplishing without
incurring in its drawbacks, such that loading time is practically
unchanged even with a thousand macros.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36968 a592a061-630c-0410-9148-cb99ea01b6c8
cause to miss some regeneration. So, better too much than less.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36872 a592a061-630c-0410-9148-cb99ea01b6c8
menus were (intentionally) missing, and it turns out they were needed.
Normally all invocations of INSET_MODIFY should trigger a recordUndo now.
Of course all cases have not been tested, but it should be working.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36770 a592a061-630c-0410-9148-cb99ea01b6c8
THis is a consequence of the new AtPoint mechanism. In the old
world, recordUndoInset was called before INSET_MODIFY. I reintroduced
manual recordUndoInset calls in all places that matter. I suspect
that this issue should be revisited later.
Note that recordUndoInset can now take an optional parameter that tells
what inset is concerned. This is useful because the cursor can be
either just inside the inset or in front of it.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36580 a592a061-630c-0410-9148-cb99ea01b6c8
inset-insert simply swallows the selection, while box-insert, note-insert etc.
put the selection inside the new inset.
As a side effect the toolbar icons get better names, as requested by Uwe.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36451 a592a061-630c-0410-9148-cb99ea01b6c8
A dynamic_cast is necessary when:
- the object to be casted is from an external library because we can't add Qxxx::asXxxx() to Qt e.g.:
* QAbstractListModel to GuiIdListModel,
* QValidator to PathValidator,
* QWidget to TabWorkArea,
* QWidget to GuiWorkArea;
- the object is to be casted from an interface to the implementing class, because the Interface does not know by whom it is implemented:
* ProgressInterface to GuiProgress,
* Application to GuiApplication.
A dynamic_cast can be replaced by:
- already existing as***Inset() functions, e.g.:
* asHullInset(),
* asInsetMath()->asMacro(),
* asInsetText();
- a static_cast when we are sure this can't go wrong, e.g.:
* we are sure that CellData::inset->clone() is an InsetTableCell,
* in cases where we explicitly check it->lyxCode().
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35855 a592a061-630c-0410-9148-cb99ea01b6c8
The old-style font changing macros really inherit the mode, so we have
to account for this.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35156 a592a061-630c-0410-9148-cb99ea01b6c8
something we don't know how to handle and fall back to images.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35024 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
The previous attempt messed up the inheritance hierarchy somehow. I
think.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35002 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
DispatchResult to store a flag that tells us whether we need a buffer
update or not.
So: If you find a missing one, go to an appropriate place in the
dispatch and call cur.forceBufferUpdate() or, if you don't have a cursor
but do have a DispatchResult, call dr.forceBufferUpdate().
There is one remaining call I could not move, in
TextMetrics::redoParagraph. But this looks like an emergency call when
the macro context has not been set. There are also a couple calls that
are connected with buffer creation that I commented out, since the same
call is done again almost immediately. But I'm not positive about those.
Now the nice thing would be to do the same for updateMacros().
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34826 a592a061-630c-0410-9148-cb99ea01b6c8
empty line of substack, tabular and xymatrix, but not calling delEmptyLastRow
for them.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34763 a592a061-630c-0410-9148-cb99ea01b6c8
deleted not only for "array" but also for all inner-hull grid types.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34752 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
equivalent to \langle and \rangle, which were already taken into account.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34607 a592a061-630c-0410-9148-cb99ea01b6c8
They differ from their cousins only for the space left around them.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34604 a592a061-630c-0410-9148-cb99ea01b6c8
This is also in preparation of a decent fix for bug #3900.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34347 a592a061-630c-0410-9148-cb99ea01b6c8
\mathbb{\underbar{a}} is not correctly rendered on screen.
We really have to change the font set, but not always.
This cannot be done using an "if" statement, as when
the FontSetChanger scope ends, everything is restored,
defeating our change. Thus, this has to be done in the
FontSetChanger class itself. This is easily accomplished
by introducing a boolean with a default value of true
for really changing a font set.
This will also be useful in other cases that I am discovering.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34312 a592a061-630c-0410-9148-cb99ea01b6c8
in mathed, so implement a strategy which is immune to color changes.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34311 a592a061-630c-0410-9148-cb99ea01b6c8
such as \mathbf{\hat{a}} would not be correctly rendered on screen.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34297 a592a061-630c-0410-9148-cb99ea01b6c8
Solution: don't use boost::bind for msvc10 (could also be extended to several GCC versions)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34257 a592a061-630c-0410-9148-cb99ea01b6c8
actually a general LyX bug, but I'll report that to the list.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33991 a592a061-630c-0410-9148-cb99ea01b6c8
