As it was, the comparison buffer was sharing a DocumentClass with
one of the compared buffers. I don't fully understand why this was
causing a problem, since we use a shared_ptr. But this patch creates
a new DocumentClass for the new buffer.
N_() is a preprocessor macro to mark translatable static strings. It is not a
good idea to also name a class member variable N_: It did only work in the
other build configurations because gettext.h was not included.
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.
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?
(P.S. Compare this to the fact that you're not supposed to refer to x and ++x in one statement.)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33137 a592a061-630c-0410-9148-cb99ea01b6c8
The feature should now be up and running, although it might have some performance issues. Please test with small changes :S as it scales quadratic with the size of a single change.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32930 a592a061-630c-0410-9148-cb99ea01b6c8
I hope I'm not reinventing the wheel too much here. This might change anyway if this appears to be a performance bottleneck.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32929 a592a061-630c-0410-9148-cb99ea01b6c8
With this patch, we can recursively walk through the document. The document is split around a middle snake and each part is processed further. The snakes are added to the output document as well as the added and deleted parts.
Now, the only thing left is to commit the implementation of the find_middle_snake function.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32591 a592a061-630c-0410-9148-cb99ea01b6c8
Furthermore:
- increase safety,
- improve error handling,
- minor cleanups,
- set documents to read-only while running the thread.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31736 a592a061-630c-0410-9148-cb99ea01b6c8