When a buffer is in an embedded work area (adv. find&replace), it is
not found by BufferList:::exists(), and therefore the undo group
created in GuiApplication::dispatch and in the handling of
LFUN_COMMAND_SEQUENCE will not be closed.. Crashes can ensue, as
described in Ubuntu bug:
https://bugs.launchpad.net/bugs/1737429
The solution is to introduce BufferList::isInternal and act on it.
Fixes bug #10847.
This is a mechanical replacement. For now it seems that unique_ptrs are
essentially used for exception-safety. More could certainly be done to clarify
pointer ownership in general.
whether a given child Buffer is also a child of some other parent.
Then do the releasing or resetting where this method is called.
There should be no change of behavior with this patch.
Previews are now generated when previews are turned on in
preferences. This change ensures that when users activate previews
for the first time, they are not confused by no previews showing up
(a restart of LyX or a triggering of each individual preview would
be required).
There was a previously attempted fix for #9507 at 390ae054 which was
reverted at 358745d0 for performance reasons: it updated previews
after every preference change and updating previews is costly (even
if the cache signals there are no changes needed).
This implementation is consistent with what we do for updating the
system fonts in preferences.
The referenced commit lead to performance issues and possibly
crashes in some cases when saving preferences. Thanks to Guillaume
for discovering the issues. See #9828 for more discussion.
I hope to come up with a better fix for #9507.
This reverts commit 390ae05444.
Normally the theBufferList().updatePreviews(); statement would go inside
of PrefDisplay::applyRC. However, that would not work well because
Buffer::updatePreviews() calls loader() which conditions on
(lyxrc.preview == LyXRC::PREVIEW_OFF) but the new RC has not been set at
this point.
Using a static variable here was premature optimization: fileNames() is only
called from GuiRef (directly or indirectly), and since this is a dialog the
copying of a FileNameList is not noticeable at all.
for possible thread conflicts, of the sort Georg resolved at
6a30211f. I have made static variables const where possible,
and marked cases that looked potentially problematic with the
comment:
// FIXME THREAD
Many of these definitely are vulnerable to concurrent access, such
as the static variables declared at the start of output_latex.cpp.
Suppose, e.g., we were outputting latex and also displaying the
source of a different document.
I'd appreciate it if others could grep for "FIXME THREAD" and see
if some of these are harmless, or what.
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?
This restores \input@path handling, which turns out to be necessary, as
the TEXINPUTS mechanism is not used with relative paths. It turns out
that both methods must be used, because \input@path does not work in all
cases (most notably with tikz).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39918 a592a061-630c-0410-9148-cb99ea01b6c8
Does anyone have a clue why nvec is declared static here ? Or can I remove it ?
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35920 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
This commit fixes such behaviour, and performs the update immediately.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32794 a592a061-630c-0410-9148-cb99ea01b6c8
Replaced various replica of such check with the invocation of the new method.
TocBackend now does not call addToToc() for internal buffers.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31340 a592a061-630c-0410-9148-cb99ea01b6c8
The mixing of internal and 'normal' buffers turned out to be problematic. This commit just dissociates the two types.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@26884 a592a061-630c-0410-9148-cb99ea01b6c8
