The functions reverseDirectionNeeded() and reverseDirectionNeeded() do
not rely on the Bidi class. The first one is changed into a Cursor
method, and the second one is replaced with explicit code.
The bug workaround added an extra repaint, which can be very bad when
editing large tables.
It turns out that the bug this is trying to fix is due to the handling
of LFUN_LINE_END in InsetMathGrid. Adding the same code as in
InsetMathNest fixes the problem.
The workaround can therefore be removed.
When the cursor had idx > 0 (since math-display does merging anyways),
reset cursor to the start of the inset. This looks less strange than
setting it at the end.
Now at least the basic case of a displayed equation with cursor
somewhere at top-level is handled correctly.
The math-display lfun operates at top level in the math inset.
Therefore, when the cursor is in an inner inset, it will after the
lfun be moved at top level. Unfortunately, there is no way that I know
f to detect this in Inset::doDispatch.
Even if we could, as things stand, it is difficult to keep the cursor in the
inner inset, especially if the inner inset moves : this happens for
example when moving from eqnarray to inline maths.
Therefore this fix is the best I can think of now.
Fixes part of bug #9664.
It turns out that it is always better using the copy of the MacroData
for updating the macro_ pointer to avoid problems related to the cursor
position.
This can happen when a macro is copied and then the document where
it is defined is closed. In this case, the macro survives in the
cut stack but the the buffer pointer is dangling.
The MacroData pointer is updated by MathData::metrics() which is not
called when selecting a math inset with instant preview for math on.
Thus, we have to update it in the copy constructor otherwise a crash
is almost assured when hitting Ctrl+C.
We only look once for the definition of the same macro, but we have
to always check its arguments when the same macro appears more than
once in a math inset. So, move earlier this check.
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 FIXME is not needed, this is how StyleChanger and FracChanger work:
In the constructor, they change the state of the FontInfo, and in the
destructor the state is set back. Therefore, all code that needs the changed
state, needs to be executed while the objects do still exist.
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.
Newer boost versions use complicated type traits for boost::next and
boost::prior, which do not work with the RandomAccessList iterators.
The long term solution is to use std::next and std::prev, for now supply
simple replacements for compilers that do not support C++11 yet.
This is still a hack, but a less dangerous one. The old code had a problem
if it was called from different threads, or if for some reason it would get
called recursively.
Avoid that \newcommand[x] definitions of math macros are pushed multiple
times to the preview loader.
Redefinitions (via \renewcommand[x]) are properly handled.
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
