If the reverse position corresponds to an inset, its paragraph id
does not follow the main text numbering. Typically, an inset has
only a few paragraphs, so that we would jump near the beginning of
the document. Now the cursor in LyX jumps to the right spot.
The conversion from floating point to string performed by
boost:lexical_cast does not allow specifying a precision and,
for example, values such as 0.9 are returned as 0.899999976.
The standard C++ way for performing the conversion is using
std::ostringstream which is exempt from this problem, even if
less efficient. For the sake of accuracy, boost::lexical_cast
is ditched in favor of the ostrinsgstream implementation.
In C++11 another option would be using std::to_string, but I
think it is not as efficient as the boost way and not worth
implementing through #ifdef's.
Now when double clicking on a boundary of a word, the
word is selected. This also causes single-letter words
to now be selected (fixes#9159).
Backported from bcbc162.
With the old code, the last word of a paragraph would not be added in
the completion list. The key difference is to pass `from' instead of `pos'
to FontList::fontiterator.
Slight cleanup of the code.
The lyx2lyx conversion for format 352 was incomplete: It should have been
added the \use_indices setting, but it relied on the fact that the default in
LyX for missing \use_indices is the same as the old format without that
setting used. However, the default might change in the future, and later
lyx2lyx conversions rely on that setting as well.
build_script() was already threadsafe, since it used a TempFile, and the
counter was basically not needed, but the new solution makes this obvious
and has the additional advantage that TempFile constructs the real output
file, not a dummy without extension which is not needed.
It was broken in two ways: It was not threadsafe, and it did never detect
any recursion, since the counter was decremented for each non-recursive call
and never incremented again.
This is one of the more important threadsafety issues because of export in
thread and simultanous view source. The solution is ugly, but a better one
(see FIXME) would require major rework. These static variables should not
have been used in the first place IMHO.
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.
In this case I use a mutex, so the zip status of files is shared between
threads. This is possible because a deadlock can't happen, and it should give
better performance.
Without this, you get crashes in a few second when you set the autosave
interval to one second and edit quickly (typing new words etc). The reason
is that the cloned buffer wants to insert words into the word list and
remove them again, but it lives in a different thread.
