The only real user was Text::insertStringAsLine, but this got changed
in commit 2c7152ab.
While not other place did read the value, there is a side effect of
setAutobreakRow that merges exiting paragraphs. However, this is used
in two situations
* some constructors, where the inset is empty;
* InsetTabular::toggleFixedWidth, which actually contains itself some
code to merge paragraphs.
Therefore the member and all associated code can be removed safely.
Rely only on InsetText::allowMultipar() to get this information.
Implement this method for InsetTabular and InsetBox.
Also rely on this method for disabling LFUN_PARAGRAPH_BREAK.
The computation of length on screen depend in particular of the computation of the size of an em. Many places of the code used to rely on the width of the M character, which is not really correct:
http://en.wikipedia.org/wiki/Em_%28typography%29
In digital typography, the best value to use is the point size of the font.
* Implement FontMetrics::em(), which returns the value in pixels of the EM unit.
Convert code to use it.
* Introduce Length::inPixel(MetricsBase const &), which takes the textwidth and em information from the MetricsBase object. Convert code to use it.
* Fix several places where Length::inPixel is used without a proper em value.
* add mathed_font_em() helper function. It should eventually be removed like some other functions in MathSupport.
* Add dummy implementation of FontMetrics to tex2lyx for linking purposes.
This is a bug reported and fixed by Edwin Leuven.
Here is how Edwin described it in his inimitable minimalist style:
first i merge the top-left two cells in a small, say 3x3, table
if i then merge this multicolumn cell with the remaining cell in the first row
my table ends up all bonkers
This implement horizontal scrolling of rows to allow editing insets
(math, tabular...) that are larger then the screen. The scrolling happens
as the cursor moves, in order to make sure that the cursor is always visible.
This effectively closes an 11 years old bug.
This feature is the result of the work of Hashini Senaratne as part of
Google Summer of Code 2013. The code has been cleaned-up for inclusion
and remaining bugs have been fixed.
Fixes bug: #1083.
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.
Don't create an intermediate copy (found by Jean-Marc).
I doubt that this has anything to do with the mystery crash, but it works, and
following the standard patterns is better anyway.
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.
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.
At efa0f198 I introduced a more flexible caption handling for long tables.
This was needed to fix tex2lyx bug #7412. Unfortunately this created bug #8933,
since I forgot to output captions to LaTeX which are not in any header or
footer. This was fixed at 2b941da7f, but this introduced bug #8992 (duplicate
caption output).
This commit is hopefully the final fix: Captions which are in header or footer
lines are output with the header or footer line, and captions in standard
lines are output standalone.
This commit fixes a bug uncovered by the fix to #8082:
If you create a table, select all columns in a row,
and set as multicolumn, the right border used to be unset.
each failure.
There are several places I was not sure what to do. These are marked
by comments beginning "LASSERT:" so they can be found easily. At the
moment, they are at:
Author.cpp:105: // LASSERT: What should we do here?
Author.cpp:121: // LASSERT: What should we do here?
Buffer.cpp:4525: // LASSERT: Is it safe to continue here, or should we just return?
Cursor.cpp:345: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:403: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:1143: // LASSERT: There have been several bugs around this code, that seem
CursorSlice.cpp:83: // LASSERT: This should only ever be called from an InsetMath.
CursorSlice.cpp:92: // LASSERT: This should only ever be called from an InsetMath.
LayoutFile.cpp:303: // LASSERT: Why would this fail?
Text.cpp:995: // LASSERT: Is it safe to continue here?
As discussed on the list. No automatic contents detection is done, the user
needs to use the special paste menu instead. I used the new TempFile class
for safe temporary file handling.
The documentation would go into section 2.2 of UserGuide.lyx, but I am not
allowed to edit that document.
so we can write a limited amount when using this for TOC and
tooltip output.
This should solve the problem with slowness that Kornel noticed,
which was caused by our trying to write an entire plaintext
bibliography every time we updated the TOC. We did that because
he had a bibliography inside a branch, and we use plaintext for
creating the tooltip that goes with the branch list.
Other related bugs were fixed along the way. E.g., it turns out
that, if someone had an InsetInclude inside a branch, then we would
have been writing a *plaintext file* for that inset every time we
updated the TOC. I wonder if some of the other reports of slowness
we have received might be due to this kind of issue?
This patch implements 'move row' and 'move column' features for tabular.
The purpose is to provide a useful behavior in tabular that is
consistent with PARAGRAPH_MOVE_UP and PARAGRAPH_MOVE_DOWN so that the
user can, for example, do alt-<up> to move a row up. Alternatively,
icons for these features are also added to the table toolbar and
context menu.
If there is any selection, the feature is disabled. This is consistent
with how PARAGRAPH_MOVE_UP works in other contexts. Additionally, 'move
row' is disabled if there is a multi-row in the current or target row;
and 'move column' is disabled if there is a multi-column in the current
or target column.
'move row' moves only the left and right borders of a cell along with
the row. Similarly, 'move column' moves only the the top and bottom
borders.
Implementing similar functionality for other insets, such as arrays and
array environments, is on my TODO list.
Fix#4981:
If the first or last column is deleted, the borders are preserved.
Similarly for the last row, but not for the first row. Selections are
supported.
Based on a patch by Zahari Dimitrov.
Fix the following bug:
When in tabular, enter "ab" in a cell. Place the cursor before "b". Hold
shift and press <right>, then (still holding shift) <right> again. On
the second <right> nothing appears to happen.
Related to #1802.
Fix#4981:
In tabular if a vertical selection is made with the keyboard (e.g.
LFUN_UP_SELECT), the selection is drawn if there are two cells selected.
Previously, the selection would be drawn only if there were more than
two selected.
If you have a selection across cells in tabular, moving the cursor
vertically up or down (e.g. LFUN_UP) now removes the drawn selection.
Before, the selection was set to false but it was not repainted.
Fixes 2 issues:
1. LyX uses for a decimal alignment a multicolumn and having for a cell a multicolumn _and_ a multirow is invalid LaTeX.
2. It was impossible to unset a decimal alignment via the context menu or toolbar button.
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
