Otherwise, we will ask about it again next time, when the file
may have changed. Also, if we crash again, we'll over-write that
file, which we may not want to do.
See bug #11464.
We need to do this unconditionally, since there is no (trivial and non-
awkward) way to update it when the bibliography paragraphs are modified.
Fixes: #4899
This adds a new (boolean) parameter "active" to the label cache, where
we track whether a label is deleted in ct mode (the same could be done,
if wanted, for labels in notes and inactive branches).
Deleted (inactive) labels are neither considered in the uniqueness check
nor added to the outliner. This also means that undeleted references to
deleted labels are now (correctly) marked as BROKEN.
Fixes: #6563
https://marc.info/?l=lyx-devel&m=154458979925296&w=2
This is related to the fix for #9158 and the caching of bibfile
information. On Windows, it is incredibly slow to run kpsewhich,
which we do to check where files actually are, so as to get info
about them (e.g., timestamps). So we have started to cache that
as a map. The map is supposed to be invalidated when various
things happen, but an oversight was causing it to be invalidated
on every cut operation. This is because cutting uses a temporary
Buffer, and the operations on it were affecting the *global* cache
of biblio file info. (It makes sense to have a global cache, since
these files are not document-specific.) Basically, we have to update
the list of bibfiles in that temporary Buffer---but that is one of
the things that invalidated the cache. The solution is only to
invalidate the cache if the list of bibfiles has actually changed
(a sensible idea anyway). The only time that will happen in the
temporary Buffer is when the copied information contains a BibTeX
inset. That should be fairly rare.
Previously the permission were destroyed by the newly created
temporary file -- which is later used as new saved file.
Tested on symlinks as well but only on Linux.
The problem with the previous attempt was that, every time through
updateBuffer, we looked up the file location using kpsewhich, which
took too long on Windows. The new solution is to cache that info, and
to look it up only when we need it.
Previously, this info would have been re-read whenever we parsed the
bibfiles. So we re-read it now whenever the bibinfo cache is invalid,
which is less often, but should be good enough. We can add more such
re-reads if need be.
The problem with the previous attempt was that, every time through
updateBuffer, we looked up the file location using kpsewhich, which
took too long on Windows. The new solution is to cache that info, and
to look it up only when we need it.
Previously, this info would have been re-read whenever we parsed the
bibfiles. So we re-read it now whenever the bibinfo cache is invalid,
which is less often, but should be good enough. We can add more such
re-reads if need be.
As of LaTeX2e 2018, characters are made active earlier, which results
in new expansion problems.
Following a suggestion of Markus Kohm (pc) and the TL mailing list [1],
we embrace non-ASCII input paths in \detokenize. This relies on e-tex,
but I think we can assume this is nowadays available everywhere.
[1] http://tug.org/pipermail/tex-live/2018-May/041691.htmlFixes: #11146
It is now possible in the float settings (doc dialog) to specify a global
(inner) alignment for floats, and in the float settings, this can be
overridden (just as with float placement)
Fixes: #8665
File format change.
Currently if we have a 2.3 file and we open it with a more recent version
we get:
original file: file.lyx
backup file: file-lyxformat-544.lyx~
After this commit the backup file becomes
file-lyx23.lyx~
If the file is from a development version then we get the same result as before.
The problem was that, if we killed export when some graphic was
being converted, or some external template was being handled, it
would only cancel that process, and then it would just continue.
To deal with that, we need to do a few things:
1. Modify the return values for some of the Converters routines,
and similarly the routines for external templates, so we can
tell when something has been canceled.
2. Throw an exception from InsetGraphics or InsetExternal when this
has happened during export, but ONLY when the Buffer is a clone.
We shouldn't be able to 'cancel' export when we're, say, generating
code for the preview pane, but this keeps us on the safe side..
The exception then has to be caught, obviously, back in the export
routines in Buffer.
Probably Coverity will be unhappy about something here, but I'll
deal with that problem as it arises.
This is mandatory for some features (such as bookmarks,pdfusetitle)
to work, and only a handful of drivers can be auto-detected by hyperref.
Fixes: #6418
Since CheckTeX itself processes the tex file, a synchronous run with
a TeX process can lead to all sorts of conflicts, including crashes.
Fixes: #7434.
This is needed for cases where the temp file has to be manually removed
at some point (e.g., if temp files are used as conversion target, and
the initial file only serves as a placeholder), since QTemporaryFile
objects cannot be manually removed at least on Windows (they are always
kept open internally even after close()). See
http://lists.qt-project.org/pipermail/interest/2013-August/008352.html
In order to avoid race conditions due to duplicate names (the issue why
the old method was removed), we record all used temp file names.
Fixes: #9139
Now the helper class contains logic that checks whether buffer are
known before closing them. This avoids potential crashes.
Use it in different places to siplify code. It is not clear at this
point whether it should be used everywhere.
Followup to bug #10847.
Along the lines suggested by JMarc, we now collect the list of bibfiles
in use in the updateBuffer routines. This actually does simplify the code
quite a bit. See the discussion there for reasons to go this way.
No intended change of behavior. The ones that use DocIterators and
ParIterators cannot yet be changed, but they could be if we provided
the right sorts of methods, perhaps.
