Updating all previews (even if only one has changed) is more costly
than I thought. Thanks to Guillaume for tracking down this
performance issue.
This reversion is related to the reversions at 358745d0 and
a7a14395. See also #7242 and #9855.
This reverts commit 29948eec26.
Updating all previews (even if only one has changed) is more costly
than I thought. Thanks to Guillaume for tracking down this
performance issue.
This reversion is related to the reversion at 358745d0.
See also #7242 and #9855.
This reverts commit 66f527e417.
WriteStream is now built from an otexstream instead of an odocstream, and
therefore counts lines in a TexRow. Calls to TexRow are added in relevant places
in math insets.
This finishes adding line tracking for math in the source panel and for forward
search.
* TexRow now computes rows from a DocIterator. In practice, the cursor
highlighting is now correct inside insets, it is no longer restricted to the
topmost level. It certainly also makes forward-search more precise.
* Added the option to disable a texrow when not needed, for perf.
* Fixed a bug where the last paragraph was not properly highlighted.
Limitations:
* TexRow still does not handle: math (e.g. multi-cell), sub-captions, inset
arguments.
These were all flagged by "(style) The scope of the variable 'x' can be reduced."
Narowing the scope improves readability, and if it is in a loop then the
compiler will be clever enough to produce efficient code, we do not need
manual optimization for POD types.
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.
lyxfind.cpp(findNextChange, findPreviousChange, findChange, selectChange): factor the change-selection part out of the change-finding part
Text.cpp (acceptOrRejectChanges): call only selectChange
The problem is the use of cursor movement methods to update cursor.
Cursor::forwardPos() steps into insets, which is not always what we
want. The problem here is that there is a math inset just after the
accepted change, and that the cursor steps into it for some reason.
This code is a nightmare anyway.
Fixes: bug #9145
The two fixes here a obviously right, although it is not clear why they are sufficient to fix the bug. Anyway I cannot reproduce any crash with it.
* the first part just conditions a whole if/else to change_next_pos.changed(). Originally, only the if branch was concerned.
* the second part is to avoid calling CursorSlice::backwardPos() when position is 0. Doing this leads to an assertion.
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?
Using Cursor::setCursor or even BufferView::setCursor is often a bad
idea since it does not run DEPM. In this case (and other cases in
f&replace code) it is better to use BufferView::mouseSetCursor (which
should maybe be renamed...).
When using 'find' and a string is not found, this is not an error or a
surprising event. It is often expected (e.g. after searching through
the whole document for a certain string eventually you will get this
message). The exclamation mark should be reserved for messages that
are unexpected or that need extra attention, such as errors.
The forward flag is used to place the cursor behind the replaced text if it's true.
But it's not correct to move the cursor if it's false. The cursor is in front of the
replacement already after the replaceSelectionWithString() was done.
This is a patch from Scott Kostyshak. The problem it solves is as follows:
1. enable continuous spell check.
2. type a misspelled word and press space so that it has a wavy red underline.
3. right-click and choose a suggested replacement word.
4. press the backspace button.
Result: nothing happens. If you press the backspace button again, then it works as normal.
The selection code was added for the benefit of the spellchecker, but the code has been rewritten since then.
