Georg Baum wrote:
Am Mittwoch, 5. Oktober 2005 23:22 schrieb Georg Baum:
Am Montag, 3. Oktober 2005 18:09 schrieb Juergen Spitzmueller:
Did you also notice that if you insert the array which your fix in
math_parser
addresses at [1], save and reload, that the last \hline has vanished?
Georg Baum wrote:
Ping! We need to do something about this. I attach the patch again (ageinst
current CVS).
It fixes the two bugs I am aware of.
Jürgen
Georg Baum wrote:
> Am Mittwoch, 5. Oktober 2005 23:22 schrieb Georg Baum:
>> Am Montag, 3. Oktober 2005 18:09 schrieb Juergen Spitzmueller:
>
>> > Did you also notice that if you insert the array which your fix in
>> math_parser
>> > addresses at [1], save and reload, that the last \hline has
Georg Baum wrote:
> Ping! We need to do something about this. I attach the patch again (ageinst
> current CVS).
It fixes the two bugs I am aware of.
Jürgen
Am Mittwoch, 5. Oktober 2005 23:22 schrieb Georg Baum:
Am Montag, 3. Oktober 2005 18:09 schrieb Juergen Spitzmueller:
Did you also notice that if you insert the array which your fix in
math_parser
addresses at [1], save and reload, that the last \hline has vanished?
Almost: It does not
Am Mittwoch, 5. Oktober 2005 23:22 schrieb Georg Baum:
> Am Montag, 3. Oktober 2005 18:09 schrieb Juergen Spitzmueller:
> > Did you also notice that if you insert the array which your fix in
> math_parser
> > addresses at [1], save and reload, that the last \hline has vanished?
>
> Almost: It
Am Montag, 3. Oktober 2005 18:09 schrieb Juergen Spitzmueller:
Georg Baum wrote:
Yes, although my first thought was wrong. Actually the patch is almost
right, but it fails if you have a row with extra space (\\[2mm]).
Although there is no GUI for the latter and it is not documented, we
Am Montag, 3. Oktober 2005 18:09 schrieb Juergen Spitzmueller:
> Georg Baum wrote:
> > Yes, although my first thought was wrong. Actually the patch is almost
> > right, but it fails if you have a row with extra space (\\[2mm]).
> > Although there is no GUI for the latter and it is not documented,
Daniel Watkins wrote:
This stops the crash, but the undo does not work perfectly. If there is a
blank row at the bottom of the matrix, it is not restored. If there is more
than one empty row, only the bottom one is removed, but another one is
removed if the delete/undo is repeated, until there
Am Montag, 3. Oktober 2005 09:56 schrieb Juergen Spitzmueller:
This is a separate bug (# 2067 now). The bug is actually not in undo,
but in
MathGridInset::write. This means that a matrix with several empty rows
is
also exported to LaTeX incorrectly, because the end-of-line command was
not
Georg Baum wrote:
Unfortunately not :-( I changed the math parser some time ago to ignore
the last row if it is empty (see delEmptyLastRow). This is needed for
arrays with hlines after the last row.
If something has to be changed, then in the math parser (e.g. one could
only ignore the empty
Am Montag, 3. Oktober 2005 14:53 schrieb Juergen Spitzmueller:
Georg Baum wrote:
Unfortunately not :-( I changed the math parser some time ago to
ignore
the last row if it is empty (see delEmptyLastRow). This is needed for
arrays with hlines after the last row.
If something has to be
Georg Baum wrote:
Yes, although my first thought was wrong. Actually the patch is almost
right, but it fails if you have a row with extra space (\\[2mm]).
Although there is no GUI for the latter and it is not documented, we
should get this right.
OK.
I am working on this now (unfortunately
On Mon, Oct 03, 2005 at 09:56:09AM +0200, Juergen Spitzmueller wrote:
Does this look sensible?
Jürgen
P.S.: the context of the changes:
void MathGridInset::write(WriteStream os) const
{
[...]
string const s = verboseHLine(rowinfo_[nrows()].lines_);
if (!s.empty() s !=
Daniel Watkins wrote:
> This stops the crash, but the undo does not work perfectly. If there is a
> blank row at the bottom of the matrix, it is not restored. If there is more
> than one empty row, only the bottom one is removed, but another one is
> removed if the delete/undo is repeated, until
Am Montag, 3. Oktober 2005 09:56 schrieb Juergen Spitzmueller:
> This is a separate bug (# 2067 now). The bug is actually not in undo,
but in
> MathGridInset::write. This means that a matrix with several empty rows
is
> also exported to LaTeX incorrectly, because the end-of-line command was
Georg Baum wrote:
> Unfortunately not :-( I changed the math parser some time ago to ignore
> the last row if it is empty (see delEmptyLastRow). This is needed for
> arrays with hlines after the last row.
> If something has to be changed, then in the math parser (e.g. one could
> only ignore the
Am Montag, 3. Oktober 2005 14:53 schrieb Juergen Spitzmueller:
> Georg Baum wrote:
> > Unfortunately not :-( I changed the math parser some time ago to
ignore
> > the last row if it is empty (see delEmptyLastRow). This is needed for
> > arrays with hlines after the last row.
> > If something has
Georg Baum wrote:
> Yes, although my first thought was wrong. Actually the patch is almost
> right, but it fails if you have a row with extra space (\\[2mm]).
> Although there is no GUI for the latter and it is not documented, we
> should get this right.
OK.
> I am working on this now
On Mon, Oct 03, 2005 at 09:56:09AM +0200, Juergen Spitzmueller wrote:
> Does this look sensible?
>
> Jürgen
>
> P.S.: the context of the changes:
>
> void MathGridInset::write(WriteStream & os) const
> {
> [...]
> string const s = verboseHLine(rowinfo_[nrows()].lines_);
> if
20 matches
Mail list logo
