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.
This avoids dataloss in case we are unable to write the new one after
all.
A more sophisticated approach, due to Georg, is in master, but it needs
more testing that it will be able to get before the release of 2.1.1.
That should be committed to 2.1.x when it is ready and this patch backed
out again.
On startup, the default locale is "C", meaning that all system
functions assume an ascii codeset. The environment's locale
settings should be selected by calling setlocale(LC_ALL,"").
This is done by Qt during the QCoreApplication initialization
but this inizialization is never performed for batch processing
and, as a result, LyX is not able to process files whose names
contain non-ascii characters. This is not an issue on Windows,
where the file names are always stored as UTF-16, so the call is
only performed for unix-like platforms (this also includes cygwin,
due to its own filenames management that allows using characters
which are forbidden to native programs).
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
This fixes a crash in examples/fa/splash.lyx when selecting text
representing menu entries. This happens because menu names are in LTR
English, while the inset itself is in RTL.
The problem is that the current code relies on the fact that
1. getColumnNearX and checkInsetHit share the same idea about cursor
position.
2. pos and pos + 1 are in general consecutive on screen.
It seems that 1. is wrong here (for reasons I did not try to
understand); the second assumption is definitely false with
bi-directional text. This makes editXY very fragile.
The new code should be more robust in this respect. The logic is:
* if checkInsetHit finds an inset, use its position,
* otherwise, ask getColumnNearX for the cursor position.
Fixes: #9142
temporary name, then move it to its real location if we succeed.
This prevents our over-writing the existing file with a corrupt
one.
(cherry picked from commit 10364082c8)
When deciding whether a paragraph should be indented or not, LyX
only takes into account default layouts. This is wrong, because
an environment could be nested into another one and thus a following
paragraph would not be "default". With this patch all paragraphs
after an environment are correctly indented, independently of
whether their layouts are "default" or not.
The latex output (which was modeled following the previous wrong
assumption) is also correspondingly adapted.
No status line needed as this is the completion of previous patches.
If a new paragraph is created just before a nested environment,
the indentation of the nested environment is not computed
correctly because the parindent of the previous layout would
also be erroneously taken into account. This would cause the
nested environment to move back and forth when something is
added to the new paragraph.
A proper status line covering this change is already present.
through this routine, which means: one for every character, more
or less. So long strings would hit the "recursion limit". But what
we are worried about is an infinite loop caused by misues of macros,
so that is what we need to count.
LyX fails to indent on screen a standard paragraph when it is
nested into an environment. The fix is a one-liner but the diff
is larger because it also fixes a previous wrong indentantion
in the source ;)
No status line needed because this is an extension of f5a246b1.
The real problem is the encoding of latex_language: It is hardcoded to latin1,
but InsetListig uses the currently active encoding. Therefore, we cannot tell
whether any given character wil be encodable or not, and we should not prevent
non-ACII characters.
In the future, we need to make the encoding of latex_language dynamic, so that
it always represents the currently active encoding. Then, we could do the
correct check both for listings and ERT. For now, I simply disabled the
encoding check for listings, which also means that bug 9012 might occur in
other cases for listings, but this is less important than bug 9102.
LyX assumes that a standard paragraph following a layout with
NextNoIndent==false has to be indented on screen, so output the
necessary blank line to make it so also in the output.
If a layout has NextNoIndent set to true, the following paragraph
is not indented on screen. LyX checks the previous layout for that
style parameter to decide whether to indent or not. Of course,
what matters is the latex output and the on-screen representation
should match this output. Now, when a layout has NextNoIndent==true,
the latex output is correctly not indented, while the on-screen
representation may fail to match this output. This can occur when,
for example, a standard paragraph is nested in the previous layout,
because LyX would check the property of the nested layout instead
of the container layout. Thus, LyX should check the property of a
previous layout at the same depth for correctly deciding whether
a paragraph has to be indented or not.
See also http://www.lyx.org/trac/ticket/9055#comment:12 for an
example document where the previous scenario actually occurs.
case where there are unbalanced braces, but it comes too late. In that
case, we try to check cmd[docstring::npos] and crash.
(cherry picked from commit 6b0a8fbc96)
to try to access whichever thing we did not find. So do an emergency
close of this Buffer.
(cherry picked from commit 5e557e7f7688e4af5bbecc49f3f7dda80afde44e)
In the current code each paragraph contains a map<Language,
WordList*>, which means that it contains a full copy of the language
object. Since these objects contain translation tables nowadays, this
is a very bad idea.
This patch simply replaces the Language key by a string.
When loading the Userguide on linux/x86_64, the total memory
consumption decreases from 36.27MB to 31.50MB.