Multirows were introduced in 8bb69f24 (Uwe Stoehr, 11 Feb 2010). In the
computation of the nearest cell, it was forgotten to account for the
vertical offset. tabular.cellHeight is the full height of the cell, while
the point that comes from the coordCache is offsetted by VOffset.
Therefore, we have to subtract the VOffset from o.y_.
"from-dialog" is added to the LFUN_INSET_MODIFY function when it is issued from the table settings dialog. This is done to prevent the checking of the individual parameters, because it has to consider all parameters alltogether. Besides, when issued from the dialog it is already guaranteed that the parameters are valid.
This parameter should not be passed onto tabularfeatures.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40376 a592a061-630c-0410-9148-cb99ea01b6c8
A long standing bug has been fixed in GCC 4.7, the bug was a non-
sactioned extra lookup. This caused some code to work that really
shouldn't.
The fixes are: add this->, Class::, or move functions about
as required to fullfill the rules.
In this case some template instantiations
where move to after what they reference.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39813 a592a061-630c-0410-9148-cb99ea01b6c8
Otherwise, we were asking to construct strings of random size at a
certain point, e.g., two 2GB strings, in one case I saw.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38704 a592a061-630c-0410-9148-cb99ea01b6c8
As the bug report notes, you do NOT get this crash if you move up or
down in the table a bit before you do the rest. The reason is that
moving up and down sets the cursor's x_target_, and it is because that
is not set that we enter the other code at all and eventually crash.
That is, in InsetTabular's dispatch, we have:
(*) cur.pos() = tm.x2pos(cur.pit(), pm.rows().size()-1, cur.targetX());
You can see the potential for trouble here already. cur.pit() is in the
NEW cell, i.e., the one to which we are moving; it was changed a few
lines previously, and cur.idx() points to the new cell, too. But we are
trying to calculate cur.pos(), which means that cur.pos() is currently
the one from the OLD cell. So the cursor is in an inconsistent state.
Calling cur.targetX() leads us to call Cursor::getPos(), and that is
what causes the crash.
We fix the problem by making sure we call targetX() on the original
cursor. The same problem clearly exists in the DOWN stuff, so we fix
that, too.
By the way, should we be setting x_target_ here once we have calculated
it?
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38530 a592a061-630c-0410-9148-cb99ea01b6c8
Currently, if an inset outputs a newline, the new latex row is still
associated with a previous id/pos. Now, if a latex error occurs before
this newline, we would still highlight everything associated to that
id/pos, even if it is extraneous to the error.
This is avoided by associating the new latex row with the id/pos in
effect right before entering the inset. If an inset does not output
a newline, it is not excluded from the selection, consistent with the
fact that the text of the inset does appear in the error description.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37903 a592a061-630c-0410-9148-cb99ea01b6c8
- (getLastCellInRow): fix crash when in first multirow row
- (TeXRow): do not output row separator in in last row (bug #7294).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37709 a592a061-630c-0410-9148-cb99ea01b6c8
This went in without discussion and is IMHO wrong (bug #7055 is invalid).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37676 a592a061-630c-0410-9148-cb99ea01b6c8
latex error occurs inside a table, the exact faulty table row is spotted.
However, if all cells of a table row are output on the same line, lyx is
not able to tell what cell caused the error and highlights the last cell
of the row. This patch allows to output each cell of a table on its own
line, such that the exact point where the error occurred can be highlighted.
Note that this is only done when exporting for preview, and in normal (nice)
exports everything goes as usual.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37643 a592a061-630c-0410-9148-cb99ea01b6c8
counting when exporting to latex. This is done for the code comprised
between \begin{document} and \end{document}, while the preamble code
still needs manual calls to TexRow::newline() for registering new lines.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37584 a592a061-630c-0410-9148-cb99ea01b6c8
blank lines may be inadvertently output. This is achieved by using two
special iomanip-like variables (breakln and safebreakln) in the lyx::
namespace. When they are inserted in the stream, a newline is output
only if not already at the beginning of a line. The difference between
breakln and safebreakln is that, if needed, the former outputs '\n'
and the latter "%\n".
In future, the new class will also be used for counting the number of
newlines issued. Even if the infractrure for doing that is already in
place, the counting is essentially still done the old way.
There are still places in the code where the functionality of the
class could be used, most probably. ATM, it is used for InsetTabular,
InsetListings, InsetFloat, and InsetText.
The Comment and GreyedOut insets required a special treatment and a
new InsetLayout parameter (Display) has been introduced. The default
for Display is "true", meaning that the corresponding latex
environment is of "display" type, i.e., it stands on its own, whereas
"false" means that the contents appear inline with the text. The
latter is the case for both Comment and GreyedOut insets.
Mostly, the only visible effects on latex exports should be the
disappearing of some redundant % chars and the appearing/disappearing
of null {} latex groups after a comment or lyxgreyedout environments
(they are related to the presence or absence of a space immediately
after those environments), as well as the fact that math environments
are now started on their own lines.
As a last thing, only the latex code between \begin{document} and
\end{document} goes through the new class, the preamble being directly
output through odocstream, as usual.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37360 a592a061-630c-0410-9148-cb99ea01b6c8
longtable or not, e.g., in the docbook and xhtml output routines.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37204 a592a061-630c-0410-9148-cb99ea01b6c8
of things like:
pit.push_back(CursorSlice(*this));
which I've had to change to:
pit.push_back(CursorSlice(const_cast<InsetCaption &>(*this)));
and similarly in a few other places.
If anyone thinks we should instead have:
explicit CursorSlice(Inset const &);
then we can also do that.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37192 a592a061-630c-0410-9148-cb99ea01b6c8
The problem is/was that when copying an InsetTableCell?, the macrocontext_position_ and the buffer_ were not copied. That's why in InsetTabular?@splitCell@521 and in InsetTabular::TeXRow() and in InsetTabular::metrics we manually copy this into the new object.
However, splitCell() returns the object by-value. So, when we call
InsetTableCell tail = splitCell(head, column_info[c].decimal_point, hassep);
the new object is copied into tail and we lose the buffer_ and macro_contextposition. Later we will crash.
What does *nix in this case ? Apparently they don't make buffer and/or macro_contextposition 0.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37072 a592a061-630c-0410-9148-cb99ea01b6c8
menus were (intentionally) missing, and it turns out they were needed.
Normally all invocations of INSET_MODIFY should trigger a recordUndo now.
Of course all cases have not been tested, but it should be working.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36770 a592a061-630c-0410-9148-cb99ea01b6c8
