The assignment name = sub.str(1) reads from the first argument given to
regex_match(), but previously this was a temporary object which was already
out of scope. This did probably not matter much in practice, but invoked
undefined behaviour, and as we all know this is allowed ton format your hard
disk or kill to your cat, so better fix this.
This is different from bug #8999, since in this case a new macro instance is
created. You still get a TeX capacity exceeded error if you try to typeset the
exported document, but this is the same as for bug #8999 and better than a
crash.
Thanks to maciejr we know now what the remaining problem was with bug 7954:
My unicode symbol fallback works fine, the problem was that a font named
"Symbol" is available on OS X, but it does not use the font-specific encoding
we expect: Almost all glyphs are at their unicode code point.
Therefore the bug is fixed by re-enabling the unicode workaround and blocking
the Symbol font on OS X.
BufferParams::setDocumentClass() deletes the old document class of the buffer
and creates a copy of the new one. Therefore, the stored layout pointers in
the paragraphs (actually only one paragraph exists) are dangling afterwards.
Resetting them before setting the document class helps here.
In the long term we need to get rid of BufferParams::setDocumentClass()
completely, this is very ugly.
Invoking a computer algebra system program for computing a selected
subformula has never worked (checked with all LyX versions back to 1.3)
and, moreover, in the presence of a selection things go awry.
This commit allows this computation by replacing the selected
subformula with the result of the computation.
much easier to find what you need, especially when we're trying
to help users. Previously, they were sorted by their enum values.
(cherry picked from commit de3daf040b)
mhchem loads amsmath and needs therefore be loaded after it but before packages that redefine commands of amsmath. We already take care of esint but not of wasysym
The check for a latex format is very fragile. Both libmagic and our
guessing from contents cannot distinguish the pstex and pdftex formats
used by the xfig external inset. Moreover, it may also happen that
lyx files are mistaken as latex ones. Thus, when the guessed format
is latex, the only solution is to give precedence to the format
determined by the file extension.
Multirow cells now have the same alignment rendering in LyX
as in the output. The alignment of a multirow can change as
long as the column is not of fixed width. If the column is
of fixed width, the multirow is left-aligned.
When setting a multirow, the alignment is copied from
the last cell in the selection.
The command line argument -geometry WIDTHxHEIGHT±XOFF±YOFF
specifies a preferred size and location for the main window.
Currently, this is semi-broken on Windows. Indeed, only
specifying WIDTH and HEIGHT places the main window such that
the left and top borders are invisible such that the window cannot
be moved. Moreover, the XOFF and YOFF parts (when present) are
used to specify the distance of the window from the left and top
or right and bottom edges of the screen, when using '+' or '-',
respectively. However, -geometry 800x600-20-20, instead of placing
the window such that its bottom and right edges are at a distance
of 20 pixels from the corresponding screen edges, places the
window such that its left and top borders are out of the screen.
This is corrected by this commit.
Investigation of bug #9236 showed that crash to be due to a Paragraph's
holding a dangling pointer to an old and deleted Layout after the
DocumentClass was reset. Since the backtraces look almost identical, it
seems likely that we have the same problem here.
Since this crash seems almost always to involve tables, I looked at the
code in switchBetweenClasses() and found that the Paragraphs that belong
to "hidden" table cells are not seen by the initial recursion using a
ParIterator: It skips right over them. This was confirmed by test code
suggested by Enrico, with results reported in Trac.
The present patch attempts to deal with this problem in the second
recursion, over Insets. When we see an InsetTabular, we call a new
routine that recurses through the cells, looking for hidden ones. If it
finds a hidden one, it then resets the Layout for the cell's Paragraphs
(there should be only one, but we do not make any assumptions) to the
PlainLayout that belongs to the new DocumentClass. This is good enough,
since such cells never have content.
There is extensive discussion of the patch here:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg185095.html
Additional testing by Enrico and me confirmed the existence of the
dangling pointer.
(cherry picked from commit 54c2ab2732)
If LyX does not know about a given file format, it may easily
happen that the format is recognized as "latex" and this causes
bug #9146. This patch limits the check for a latex format to
non-binary files. The strategy for deciding that a file has
binary content is the same as that adopted by the "less" program.
This is a stripped down backport of the more complex fix in master.
For Windows: AcroRd32, SumatraPDF and gsview (both 32 and 64 bit versions).
For Unix: qpdfview.
Qpdfview is a nice alternative to Okular for KDE users and a superior
alternative to Evince for Gnome users, due to its complete synctex
support. It only depends on Qt libraries for the graphical interface.
Forthcoming versions of cygwin will use a different mechanism for
obtaining passwd/group information based on /etc/nsswitch.conf.
Thus, it will not be guaranteed that the files /etc/passwd and
/etc/group even exist. The recommended way for obtaining those
info is by using the getent command, which already works in
current versions.
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.
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)
trim_eol() assumes that a line always ends either with \n, \r, or \r\n.
This assumption is always valid except for the last line of a document, since it
may miss the trailing newline. LyX does not create such documents, bu they may
result from automatic creation tools, and LyX can read them, so lyx2lyx should
be able to read them as well.
(cherry picked from commit c75c6e446a)
Fix the fix
MAC-style (pre-OS X) line ends were not recognized anymore
(cherry picked from commit 55af9cb006)
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)
lyx2lyx sets all new math packages to off when converting from old formats.
This is correct if any command which would cause an automatic package loading
exists in the document. However, it is wrong if no command exists: This leads
to problems if later a command is added (bug #9069), which is especially
annoying for templates.
The fix consists of two parts:
1) convert_use_package() considers now the used commands like
revert_use_package(), and uses them to decide whether to set the package to
auto or off.
2) convert_undertilde() and revert_undertilde() use a slightly adjusted copy of
convert_use_package() and revert_use_package(), so that the bug is also
fixed for undertilde. We cannot use the latter functions directly, because
of "\usepackage undertilde" vs. "\use_undertilde".
When doing the lyx2lyx round trip of the 2.0.8 user guide from format
413 -> 474 -> 413 you get an invalid document, because the math packages
mhchem and undertilde are incorrectly converted.
It turned out that the old reversion code did only work for particular
package oderings. The new one works for abitrary sorted packages.
When doing the lyx2lyx round trip of the 2.0.8 user guide from format
413 -> 474 -> 413 you do not get a zero diff. The most important problem is
caused by the conversion of the argument insets to the old syntax: This
conversion adds an additional empty line (harmless), and it destroys the
document structure if the first inset in e.g. a subsection is not an argument
inset, but e.g. an index or label inset.
The fix is quite easy: Ensure that the paragraph begin is set to the first
argument inset.
revert_justification() issues a warning if the \justification parameter does
not exist, and LyX itself always writes it unconditionally as well, so add it
also in lyx2lyx when converting old documents.
Currently this does not have any user visible effect, but it decouples the
default value of BufferParams::justification from the conversion of old
documents: Now it is possible to set the default to false in LyX, and old
documents will still be converted correctly.
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.
