The two fixes here a obviously right, although it is not clear why they are sufficient to fix the bug. Anyway I cannot reproduce any crash with it.
* the first part just conditions a whole if/else to change_next_pos.changed(). Originally, only the if branch was concerned.
* the second part is to avoid calling CursorSlice::backwardPos() when position is 0. Doing this leads to an assertion.
and Cursors. So just calling InsetText::addToToc for the cells causes
problems, because InsetText::addToToc then adds the cell inset itself
as part of the DocIterator. This then leads to assertions, such as bug
The solution is to refactor InsetText::addToToc so that we can call the
iterating part without adding the inset.
(cherry picked from commit 6a85db2307)
This was an obvious thinko: When pasting a paragraph list the depth of the
pasted paragraphs need to be adjusted, so that no paragraph has a negative
depth afterwards. However, the maximum allowed depth was only adjusted after
the second and following pasted paragraphs. Since the computed value was only
used for the subsequent paragrph this meant that the second paragraph did
still use the same maximum allowed depth as the first one, which came from the
paragraph the text as pasted into. This was wrong e.g. in case the outside
paragraph was a standard paragraph (max_depth = 0), and the first pasted
paragraph was an enumeration (max_depth = 1). Therefore, max_depth needs to
be adjusted also after the first pasted paragaph. Since the adjustment is
done aftre max_depth was used for the current paragraph the condition
mentioned in the comment is still met.
(cherry picked from commit 270201ed67)
The problem was just the faulty use of CursorSlice::at_begin/end(), which does not look for end of cell, but end of inset.
(cherry picked from commit 68202fdf44)
the minibuffer. As the comments explain, this leaves a different
bug, but (a) it isn't a crash and (b) it probably won't affect
many users, if *any* users.
(cherry picked from commit 7220f1459e)
This allows the user to correct the bad input without
having to enter the other fields again in a new dialog.
Patch from Martin Hoffmann.
(cherry picked from commit 27131e655a)
Conflicts:
lib/generate_contributions.py
We are not capable of handling two bibitems within one biblio paragraph.
That's why we have functions like Paragraph::brokenBiblio() and
Paragraph::fixBiblio(). So, if we fix the biblio by deleting the second
bibitem, we should not keep it as deleted.
This code caused a crash because the inset was released, but still kept as
deleted.
Fixes-bug: #8646.
TextMetrics::getColumnNearX (x -> pos translation) has special code to
ignore spaces at the beginning of a row, but neither the display code
nor TextMetrics::cursorX (pos->x translation) follow this logic. One
might argue that spaces should actually be ignored (like LaTeX does),
but this leads to UI issues and is probably too difficult to
implement.
(cherry picked from commit bab58480bc)
http://marc.info/?l=lyx-devel&m=138590578911716&w=2
If you look at Buffer.cpp, around line 4351, there was a comment about bug 5699. We are seeing the
same crash. The problem is that, although the master does have a GUI, that GUI is in a different window. So the structureChanged() call we do during updateBuffer() is for the TOC in that window, not the TOC in the window we are actually in. So our TocModel::toc_ has been reset and is invalid, though the widget itself has not been updated and looks fine.
This patch tests whether the master is in the same window as the buffer we are updating.
A problem remains, which is noted in a comment.
(cherry picked from commit 3f62601a8f)
Conflicts:
src/Buffer.cpp
