[patch] Bug 2067 (was: Re: [Bug 2058] LyX crashes when attempting to undo matrix deletion)
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 is only one remaining.
A row with content, or the top row, will stop any more rows disappearing.
Steps to reproduce:
1) Create 3x3 matrix.
2) Cursor in top-left box.
3) Backspace.
4) Undo
Result:
An empty 3x2 matrix is restored.
Expected result:
An empty 3x3 matrix is restored.
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
written for the first empty line.
Patch attached.
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 != ) {
if (os.fragile())
os \\protect;
os s;
}
+ else
+ os ;
}
Index: math_gridinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_gridinset.C,v
retrieving revision 1.168
diff -p -u -r1.168 math_gridinset.C
--- math_gridinset.C 18 Jul 2005 00:09:20 - 1.168
+++ math_gridinset.C 3 Oct 2005 07:43:51 -
@@ -975,6 +975,8 @@ void MathGridInset::write(WriteStream
os \\protect;
os s;
}
+ else
+ os ;
}
@@ -1043,7 +1045,7 @@ void MathGridInset::doDispatch(LCursor
// FIXME: We use recordUndoInset when a change reflects more
// than one cell, because recordUndo does not work for
// multiple cells. Unfortunately this puts the cursor in front
- // of the inset after undo. This is (especilally for large
+ // of the inset after undo. This is (especially for large
// grids) annoying.
recordUndoInset(cur);
//autocorrect_ = false;
Re: Hebrew/bidi bug 1975
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin A fresh patch for bug 1975, due to the boundary changes. Martin Bugzilla doesn't like me today, so attached. Martin Still no external testers found... please?!? Did this ever got applied? JMarc
TOC generation and autogen.sh
Georg, I realise that others have been telling you of problems with the TOC-generation stuff that you played with recently. However, I haven't noticed any messages about autogen.sh output: HTH, Angus Building Makefile templates... . Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `TOCs' is a target; expected a variable lib/doc/Makefile.am:66: variable `TOCs' not defined Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `TOCs' is a target; expected a variable lib/doc/Makefile.am:66: variable `TOCs' not defined Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `distdir' is a target; expected a variable done. Building configure...
Re: LyX speedup patch
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Yes... as it happens I was today thinking along similar lines. Martin But wouldn't it be enough to just cache, e.g., the pos of row Martin end, to determine whether the current row content changes or Martin not, and if not, skip out of the rebreak and render routines? Martin Or would that become messy? This would mean implementing SingleRow update instead of SinglePar, right? JMarc
Re: Bug 2058: LyX crashes when attempting to undo matrix deletion
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Georg Baum wrote: Why don't you put the code in MathNestInset? Since backspace at the first position deletes the containing inset in every math inset I think that recordUndoInset should also be called in general. Juergen Yes, why not (I was not aware of that feature, knowing mathed Juergen basically from bug fixing). Patch attached. This looks OK. JMarc
Re: [patch] fix bug 2050
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg See http://bugzilla.lyx.org/show_bug.cgi?id=2050. Math mcros Georg that contain \kern are misrendered on screen. The fix is Georg obvious, and I could not reproduce the crash. I propose to put Georg this in. If the crash reappears we may find out the real Georg reason, but for now I think that it is gone. Georg OK? OK. JMarc
Re: Hebrew/bidi bug 1975
On Mon, 2005-10-03 at 11:31 +0200, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin A fresh patch for bug 1975, due to the boundary changes. Martin Bugzilla doesn't like me today, so attached. Martin Still no external testers found... please?!? Did this ever got applied? No... hanging in my tree. - Martin signature.asc Description: This is a digitally signed message part
Re: LyX speedup patch
On Mon, 2005-10-03 at 11:38 +0200, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Yes... as it happens I was today thinking along similar lines. Martin But wouldn't it be enough to just cache, e.g., the pos of row Martin end, to determine whether the current row content changes or Martin not, and if not, skip out of the rebreak and render routines? Martin Or would that become messy? This would mean implementing SingleRow update instead of SinglePar, right? Yes, I think so. How to do it is another matter. I suspect that caching row.endpos() internally in lyxtext would be enough. - Martin signature.asc Description: This is a digitally signed message part
Re: Hebrew/bidi bug 1975
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Did this ever got applied? Martin No... hanging in my tree. So, what has to be done? testing? How confident are you? JMarc
[patch] bug 1894: Disabling of widgets broken
It came out that the problem is caused by refreshReadOnly(), called (indirectly) by Dialog::checkStatus(). refreshReadOnly disables all widgets (that are addReadOnly()'ed) in read only mode and enables all these widgets in non-read-only mode. The latter, which is necessary to switch modes, overrides the intiial disabling of certain widgets by the dialogs. The attached patch just calls the dialog's update() after all widgets have been enabled by refreshReadOnly, so that the widgets that should be disabled actually get disabled. I have tested all scenarios I could think of (non-read-only, read-only and switches between those two modes) and saw no problems. Comments? Jürgen Index: Dialog.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/Dialog.C,v retrieving revision 1.18 diff -p -u -r1.18 Dialog.C --- Dialog.C 26 Apr 2005 09:37:52 - 1.18 +++ Dialog.C 3 Oct 2005 09:57:09 - @@ -186,11 +186,17 @@ void Dialog::checkStatus() return; } + bool const readonly = kernel().isBufferReadonly(); // check whether this dialog may be active if (controller().canApply()) - bc().readOnly(kernel().isBufferReadonly()); + bc().readOnly(readonly); else bc().readOnly(true); + + // refreshReadOnly() is too generous in _enabling_ widgets + // update dialog to disable disabled widgets again + if (!readonly) + view().update(); }
Re: LyX speedup patch
Martin == Martin Vermeer [EMAIL PROTECTED] writes: This would mean implementing SingleRow update instead of SinglePar, right? Martin Yes, I think so. How to do it is another matter. I suspect Martin that caching row.endpos() internally in lyxtext would be Martin enough. This would be almost similar to what you do with paragraph dimension caching. I guess the algorithm could be to redo the rows one by one (starting from cursor) until we find one that did not change. JMarc
Re: [patch] bug 1894: Disabling of widgets broken
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen It came out that the problem is caused by refreshReadOnly(), Juergen called (indirectly) by Dialog::checkStatus(). refreshReadOnly Juergen disables all widgets (that are addReadOnly()'ed) in read only Juergen mode and enables all these widgets in non-read-only mode. The Juergen latter, which is necessary to switch modes, overrides the Juergen intiial disabling of certain widgets by the dialogs. Juergen The attached patch just calls the dialog's update() after all Juergen widgets have been enabled by refreshReadOnly, so that the Juergen widgets that should be disabled actually get disabled. Juergen Comments? Shouldn't the update be added inside the if (controller().canApply()) block? The looks OK. Angus? JMarc
Re: [patch] bug 1894: Disabling of widgets broken
Juergen Spitzmueller wrote: It came out that the problem is caused by refreshReadOnly(), called (indirectly) by Dialog::checkStatus(). refreshReadOnly disables all widgets (that are addReadOnly()'ed) in read only mode and enables all these widgets in non-read-only mode. The latter, which is necessary to switch modes, overrides the intiial disabling of certain widgets by the dialogs. The attached patch just calls the dialog's update() after all widgets have been enabled by refreshReadOnly, so that the widgets that should be disabled actually get disabled. I have tested all scenarios I could think of (non-read-only, read-only and switches between those two modes) and saw no problems. Comments? Jürgen Hi, Jürgen. Sorry I didn't manage to get back to your bugzilla query earlier. Now all is explained, I can see why this patch is needed and why it will work. The solution looks reasonable to me. -- Angus
Re: [patch] bug 1894: Disabling of widgets broken
Jean-Marc Lasgouttes wrote: Shouldn't the update be added inside the if (controller().canApply()) block? I just thought about that, too. It's certainly safer, I'll do this. Jürgen
Re: [patch] bug 1894: Disabling of widgets broken
Jean-Marc Lasgouttes wrote: Juergen Comments? Shouldn't the update be added inside the if (controller().canApply()) block? Urgs. Probably :) Especially given that fact that view_.update() isn't needed for a read-only document. The looks OK. Angus? -- Angus
Re: [patch] bug 1894: Disabling of widgets broken
Juergen Spitzmueller wrote:
Shouldn't the update be added inside the
if (controller().canApply()) block?
I just thought about that, too. It's certainly safer, I'll do this.
OK to apply the attached?
Jürgen
BTW this bug also applies to 1.3
Index: Dialog.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/Dialog.C,v
retrieving revision 1.18
diff -p -u -r1.18 Dialog.C
--- Dialog.C 26 Apr 2005 09:37:52 - 1.18
+++ Dialog.C 3 Oct 2005 10:31:01 -
@@ -187,9 +187,14 @@ void Dialog::checkStatus()
}
// check whether this dialog may be active
- if (controller().canApply())
- bc().readOnly(kernel().isBufferReadonly());
- else
+ if (controller().canApply()) {
+ bool const readonly = kernel().isBufferReadonly();
+ bc().readOnly(readonly);
+ // refreshReadOnly() is too generous in _enabling_ widgets
+ // update dialog to disable disabled widgets again
+ if (!readonly)
+ view().update();
+ } else
bc().readOnly(true);
}
Re: [patch] bug 1894: Disabling of widgets broken
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Jean-Marc Lasgouttes wrote: Shouldn't the update be added inside the if (controller().canApply()) block? Juergen I just thought about that, too. It's certainly safer, I'll do Juergen this. OK. You can apply then. JMarc
Re: LyX speedup patch
On Mon, 2005-10-03 at 12:16 +0200, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: This would mean implementing SingleRow update instead of SinglePar, right? Martin Yes, I think so. How to do it is another matter. I suspect Martin that caching row.endpos() internally in lyxtext would be Martin enough. This would be almost similar to what you do with paragraph dimension caching. I guess the algorithm could be to redo the rows one by one (starting from cursor) until we find one that did not change. Precisely. The place would be in redoParagraph, the do...while loop on z. I wonder if this is enough, or if we should then also look at the rendering side of things. Probably. - Martin signature.asc Description: This is a digitally signed message part
Re: [patch] bug 1894: Disabling of widgets broken
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen BTW this bug also applies to 1.3 You can also apply to 1.3.x, then (after some basic testing, of course :) JMarc
[PATCH] fix macro type with math-macro
Found this while investigating 2050/2060: when creating a macro with math-macro aa, the type is set to instead of newcommand. It is an obvious typo in the code, so I'll just commit. JMarc Index: src/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v retrieving revision 1.2293 diff -u -p -r1.2293 ChangeLog --- src/ChangeLog 28 Sep 2005 15:02:45 - 1.2293 +++ src/ChangeLog 3 Oct 2005 10:50:52 - @@ -1,3 +1,8 @@ +2005-10-03 Jean-Marc Lasgouttes [EMAIL PROTECTED] + + * text3.C (dispatch): when invoking LFUN_MATH_MACRO with no type + argument, use newcommand. + 2005-09-28 Jürgen Spitzmüller [EMAIL PROTECTED] * cursor.C (setSelection): do not open collapsable insets; Index: src/text3.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v retrieving revision 1.308 diff -u -p -r1.308 text3.C --- src/text3.C 27 Sep 2005 08:42:28 - 1.308 +++ src/text3.C 3 Oct 2005 10:50:52 - @@ -1254,7 +1254,7 @@ void LyXText::dispatch(LCursor cur, Fu int const nargs = s1.empty() ? 0 : convertint(s1); string const s2 = token(s, ' ', 2); string const type = s2.empty() ? newcommand : s2; - cur.insert(new MathMacroTemplate(token(s, ' ', 0), nargs, s2)); + cur.insert(new MathMacroTemplate(token(s, ' ', 0), nargs, type)); //cur.nextInset()-edit(cur, true); } break;
Re: [PATCH] fix macro type with math-macro
Jean-Marc Lasgouttes wrote: Found this while investigating 2050/2060: when creating a macro with math-macro aa, the type is set to instead of newcommand. It is an obvious typo in the code, so I'll just commit. It may be an obvious typo, but it looks to me like it should be MathMacroTemplate itself that decides what to do with s2. Shouldn't the whole string const type = s2.empty() ? newcommand : s2; be moved into the MathMacroTemplate constructor? -- Angus
Re: [patch] bug 1894: Disabling of widgets broken
Jean-Marc Lasgouttes wrote: Juergen BTW this bug also applies to 1.3 You can also apply to 1.3.x, then (after some basic testing, of course Hm, things look quite a bit different there. I have to take time and look how 1.3 does what checkStatus does in 1.4 Jürgen
Re: Hebrew/bidi bug 1975
On Mon, 2005-10-03 at 12:08 +0200, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Did this ever got applied? Martin No... hanging in my tree. So, what has to be done? testing? How confident are you? Pretty confident, as it appears that RtL is connected to language and completely decoupled from font. That makes it possible to test without having Hebrew fonts installed... still I would have appreciated a Hebrew tester. - Martin signature.asc Description: This is a digitally signed message part
Re: Hebrew/bidi bug 1975
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin On Mon, 2005-10-03 at 12:08 +0200, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Did this ever got applied? Martin No... hanging in my tree. So, what has to be done? testing? How confident are you? Martin Pretty confident, as it appears that RtL is connected to Martin language and completely decoupled from font. That makes it Martin possible to test without having Hebrew fonts installed... Martin still I would have appreciated a Hebrew tester. Since it only affects RtL, I'd say that you should apply it. JMarc
Re: [PATCH] fix macro type with math-macro
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc Lasgouttes wrote: Found this while investigating 2050/2060: when creating a macro with math-macro aa, the type is set to instead of newcommand. It is an obvious typo in the code, so I'll just commit. Angus It may be an obvious typo, but it looks to me like it should be Angus MathMacroTemplate itself that decides what to do with s2. Angus Shouldn't the whole string const type = s2.empty() ? Angus newcommand : s2; be moved into the MathMacroTemplate Angus constructor? Yes, probably. I decided to make a minimal change, since there were so many things I wanted to rewrite in there :) JMarc
Re: Hebrew/bidi bug 1975
On Mon, 2005-10-03 at 14:00 +0200, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin On Mon, 2005-10-03 at 12:08 +0200, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Did this ever got applied? Martin No... hanging in my tree. So, what has to be done? testing? How confident are you? Martin Pretty confident, as it appears that RtL is connected to Martin language and completely decoupled from font. That makes it Martin possible to test without having Hebrew fonts installed... Martin still I would have appreciated a Hebrew tester. Since it only affects RtL, I'd say that you should apply it. Done. Let's hope we get some testing ;-) - Martin signature.asc Description: This is a digitally signed message part
Re: TOC generation and autogen.sh
Am Montag, 3. Oktober 2005 11:37 schrieb Angus Leeming: Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `TOCs' is a target; expected a variable lib/doc/Makefile.am:66: variable `TOCs' not defined Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `TOCs' is a target; expected a variable lib/doc/Makefile.am:66: variable `TOCs' not defined Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `distdir' is a target; expected a variable done. Building configure... I don't get this. Do you have my patch TOC2.diff from saturday applied? If yes, does it help to rename the TOCs target (I have both a variable TOCs and a target TOCs. Maybe automake is too stupid to handle that?) Georg
Re: [patch] fix bug 2060
Am Sonntag, 2. Oktober 2005 23:58 schrieb Angus Leeming:
I can confirm the crash but can also supply some debug info.
Thanks. The reason for the crash is the same as # 2060: MathNestInsets may
have 0 cells.
Fix attached. OK to commit? And the fix for # 2060?
Georg
PS: Daniel, many thanks for the bug reports. They are really useful.
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/mathed/ChangeLog lyx-1.4-cvs/src/mathed/ChangeLog
--- lyx-1.4-clean/src/mathed/ChangeLog 2005-10-03 13:39:19.0 +0200
+++ lyx-1.4-cvs/src/mathed/ChangeLog 2005-10-03 13:56:38.197723448 +0200
@@ -1,3 +1,8 @@
+2005-10-03 Georg Baum [EMAIL PROTECTED]
+
+ * math_nestinset.C (doDispatch): fix crash when inserting math macros
+ with 0 arguments
+
2005-10-02 Georg Baum [EMAIL PROTECTED]
* math_kerninset.C (write): write width, not 0 (fixes bug 2050)
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/mathed/math_nestinset.C lyx-1.4-cvs/src/mathed/math_nestinset.C
--- lyx-1.4-clean/src/mathed/math_nestinset.C 2005-10-03 13:12:07.0 +0200
+++ lyx-1.4-cvs/src/mathed/math_nestinset.C 2005-10-03 13:55:49.664101680 +0200
@@ -861,7 +872,10 @@ void MathNestInset::doDispatch(LCursor
int cell(0);
if (cmd.argument == \\root)
cell = 1;
- if (ar.size() == 1 (ar[0].nucleus()-asNestInset())) {
+ // math macros are nest insets and may have 0 cells.
+ // handleNest would crash in this case.
+ if (ar.size() == 1 (ar[0].nucleus()-asNestInset())
+ ar[0].nucleus()-nargs() cell) {
cur.handleNest(ar[0], cell);
} else
cur.niceInsert(cmd.argument);
Re: [patch] Bug 2067 (was: Re: [Bug 2058] LyX crashes when attempting to undo matrix deletion)
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 written for the first empty line. Patch attached. Does this look sensible? 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 row if it follows a hline), but not in MathGridInset. I currently have no time, but might think of a solution later. Georg
Re: [patch] fix bug 2060
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg See http://bugzilla.lyx.org/show_bug.cgi?id=2060. The problem Georg is that macros with no arguments are stored as a MathNestInset Georg with 0 cells, and that MathNestInset::editXY() assumes at least Georg one cell. I fixed that and added two more checks for 0 cells Georg which I think are necessary. Georg OK to commit? Should some of these tests be asserts? Otherwise, the main fix in the patch looks good. JMarc
Re: Bug 2057: Delete key acting unexpectedly in MathEd
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Jean-Marc Lasgouttes wrote: Yes, we shall remove cmd = FuncRequest(LFUN_FINISHED_LEFT); cur.undispatched(); Juergen OK. Do you happen to have a patch in hand? Jean-Marc OK, you win :) Jean-Marc This fixes the leaving of inset, and also the selection of Jean-Marc not-so-small atoms. I committed it. JMarc
Re: [patch] fix bug 2060
Am Montag, 3. Oktober 2005 14:22 schrieb Jean-Marc Lasgouttes: Should some of these tests be asserts? If you can assure me that drawSelection() and cursorPos() don't get called for macros with 0 arguments and macros with 0 arguments are the only case of a MathNestInset, then yes. Otherwise we need the real test. Georg
Re: relyx inserts spaces in tables imported from LaTeX
John == John Mongan [EMAIL PROTECTED] writes: John I believe this problem can be fixed in the BasicLyx.pm module of John reLyX by defining each new cell to be the start of a paragraph, John so that the subsequent Text will have it's leading white-space John zapped. This can be accomplished as follows: But doesn't this have some side-effects? Did you try to compare the reLyX output with and without the patch? John However, I don't begin to pretend to understand everything going John on in reLyX, so I'm hoping someone more knowledgeable than John myself might be able to comment on whether this fix is likely to John cause problems elsewhere. If it does turn out to be a legitimate John fix, I hope it might be committed for future versions. The problem is that nobody really understand reLyX currently :( It is slated for replacement with tex2lyx in 1.4.0. JMarc
Re: CVS lyx and noweb2lyx?
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Jean-Marc Lasgouttes wrote: We should see what reLyX did and port that to tex2lyx, then. Georg I did that (at least partially). It works well with the example Georg file. Georg Is it OK to apply? The use of the tex parser is indeed a bit rude :) But I see that what is done for verbatim is not really better. Georg I am not sure if I got all noweb features that noweb2lyx could Georg convert. Kayvan, could you please check whether something is Georg missing? Kayvan? JMarc
Re: [patch] Bug 2067 (was: Re: [Bug 2058] LyX crashes when attempting to undo matrix deletion)
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 row if it follows a hline), but not in MathGridInset. I currently have no time, but might think of a solution later. But this patch addresses the first row, not the last. Are you sure this is related? Jürgen
Re: [patch] fix bug 2060
Georg Baum wrote: PS: Daniel, many thanks for the bug reports. They are really useful. I have to second that. Jürgen
Re: TOC generation and autogen.sh
Georg Baum wrote: Am Montag, 3. Oktober 2005 11:37 schrieb Angus Leeming: Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `TOCs' is a target; expected a variable lib/doc/Makefile.am:66: variable `TOCs' not defined Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `TOCs' is a target; expected a variable lib/doc/Makefile.am:66: variable `TOCs' not defined Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `distdir' is a target; expected a variable done. Building configure... I don't get this. Do you have my patch TOC2.diff from saturday applied? No. I have a pristine CVS tree. If yes, does it help to rename the TOCs target (I have both a variable TOCs and a target TOCs. Maybe automake is too stupid to handle that?) I also note that it's an old version of automake (1.6) although autogen.sh is currently set up to accept it. -- Angus
Re: [patch] fix bug 2060
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Am Montag, 3. Oktober 2005 14:22 schrieb Jean-Marc Lasgouttes: Should some of these tests be asserts? Georg If you can assure me that drawSelection() and cursorPos() don't Georg get called for macros with 0 arguments and macros with 0 Georg arguments are the only case of a MathNestInset, then yes. Georg Otherwise we need the real test. What I wondering is whether MathNestInset should tell the world that it is not editable when size() == 0. It is always strange to have to add these tests all over the place. But if you think it is not possible to do better, apply this and also the other one you just posted. JMarc
[PATCH] bug 2063: Spellcheck doesn't check word containing the cursor
Here is a simple fix. Instead of going forward to put the cursor at
beginning of next word, we go backward to the beginning of current
word.
Bennett, please test.
JMarc
Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.498
diff -u -p -r1.498 ChangeLog
--- src/frontends/controllers/ChangeLog 3 Oct 2005 10:37:28 - 1.498
+++ src/frontends/controllers/ChangeLog 3 Oct 2005 13:48:23 -
@@ -1,3 +1,8 @@
+2005-10-03 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * ControlSpellchecker.C (check): make sure that word at cursor
+ position is checked too. (bug 2063)
+
2005-10-03 Jürgen Spitzmüller [EMAIL PROTECTED]
* Dialog.C (checkStatus): update dialog after checkReadOnly has
Index: src/frontends/controllers/ControlSpellchecker.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlSpellchecker.C,v
retrieving revision 1.85
diff -u -p -r1.85 ControlSpellchecker.C
--- src/frontends/controllers/ControlSpellchecker.C 8 Sep 2005 09:20:14 - 1.85
+++ src/frontends/controllers/ControlSpellchecker.C 3 Oct 2005 13:48:23 -
@@ -190,6 +190,9 @@ void ControlSpellchecker::check()
SpellBase::Result res = SpellBase::OK;
DocIterator cur = kernel().bufferview()-cursor();
+ while (cur cur.pos() isLetter(cur)) {
+ cur.backwardPos();
+ }
ptrdiff_t start = 0, total = 0;
DocIterator it = DocIterator(kernel().buffer().inset());
@@ -198,9 +201,6 @@ void ControlSpellchecker::check()
for (total = start; it; it.forwardPos())
++total;
-
- for (; cur cur.pos() isLetter(cur); cur.forwardPos())
- ++start;
BufferParams bufferparams = kernel().buffer().params();
exitEarly_ = false;
Re: [PATCH] bug 2063: Spellcheck doesn't check word containing the cursor
On Oct 3, 2005, at 9:53 AM, Jean-Marc Lasgouttes wrote: Here is a simple fix. Instead of going forward to put the cursor at beginning of next word, we go backward to the beginning of current word. Bennett, please test. Works for me. Bennett
Re: [patch] Bug 2067 (was: Re: [Bug 2058] LyX crashes when attempting to undo matrix deletion)
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 changed, then in the math parser (e.g. one could only ignore the empty row if it follows a hline), but not in MathGridInset. I currently have no time, but might think of a solution later. But this patch addresses the first row, not the last. Are you sure this is related? 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. I am working on this now (unfortunately I found more bugs while testing...) Georg
Re: lyx-devel lib/: Tag: BRANCH_1_3_X CREDITS ChangeLog
[EMAIL PROTECTED] wrote: CVSROOT: /usr/local/lyx/cvsroot Module name: lyx-devel Repository: lyx-devel/lib/ Changes by: [EMAIL PROTECTED]05/10/03 17:36:51 Modified files: lyx-devel/lib/: Tag: BRANCH_1_3_X CREDITS ChangeLog Log message: Dr. Schmitt became Mr. Gerz Patches: http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/CREDITS?r1=1.32.2.7r2=1.32.2.8 http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/ChangeLog?r1=1.363.2.124r2=1.363.2.125 Hi, Michael. Could you move your new entry into alphabetical order, please? If you want to do this in HEAD you should modify generate_contributions.py and then run it to generate CREDITS, credits.php and blanket-permission.php These latter two should be moved over to the www-user tree. Regards, Angus
Itemize inside a thanks footnote
Hello,
I've just found this bug (well it is more a LaTeX weakness) inside 1.3.6 and I
was wondering if it has been corrected in 1.4.0 before opening a bug report.
1) Create an article
2) Create a title and a footnote (\thanks)
3) Inside the thanks footnote create a bullet list
4) the generated LaTeX code won't compile because of missing \protect that I
have inserted here
like that :
%% LyX 1.3 created this file. For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[frenchb]{article}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\makeatletter
%% User specified LaTeX commands.
\usepackage{babel}
\makeatother
\begin{document}
\title{Mon article%
\thanks{\protect\begin{itemize}
\protect\item 1
\protect\item 2
\protect\end{itemize}
%
%% If you take away the 'protect', it will not compile
}}
\maketitle
Ceci est une note%
\footnote{\begin{itemize}
\item 1
\item 2
\end{itemize}
%
}
\end{document}
Cheers,
Charles
--
[EMAIL PROTECTED]
http://www.kde-france.org
Re: [patch] Bug 2067 (was: Re: [Bug 2058] LyX crashes when attempting to undo matrix deletion)
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 I found more bugs while
testing...)
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?
[1]
\begin{array}{|c|c|}
\hline
1 2 \\ \hline
3 4 \\ \hline
\end{array}
Regards,
Jürgen
Debugging Output
In one of the bugs I reported, I failed to get any CLI output at all, while Angus managed to get a whole heap of stuff. How can I go about getting the largest quantity of useful debugging info? ATM, I have stdlib debugging disabled, which may be the cause. However, it seems unlikely. Is there a debugging environment I need to run LyX under in order to get all that lovely output? I apologise for the user-like query, but it seems too related to development to put in there. :p And, incidentally, I'm enjoying contributing to a project as awesome as LyX, so thanks to all you programmers for putting bugs in for me to find. ;) Cheers, Dan
Re: Debugging Output
Daniel Watkins wrote: In one of the bugs I reported, I failed to get any CLI output at all, while Angus managed to get a whole heap of stuff. How can I go about getting the largest quantity of useful debugging info? ATM, I have stdlib debugging disabled, which may be the cause. However, it seems unlikely. Is there a debugging environment I need to run LyX under in order to get all that lovely output? LyX/Win is fundamentally a console-app. We just use a hack to get rid of the initial console window when we start up. See http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/support/os_win32.C?rev=1.8.2.19only_with_tag=BRANCH_1_3_Xcontent-type=text/vnd.viewcvs-markup and the commentary therein. So, if you've got stdlib debugging disabled, you ain't going to get no debugging info. Right? -- Angus
Bug 2069: Movement out of sub/superscript works unexpectedly
And now, ladies and gentlemen, we return you to your regular programming. A MathEd bug! Bug 2069: Movement out of sub/superscript works unexpectedly Description: When, at the leftmost end of the sub/superscript, you press left or, at any point in the sub/superscript, you press up/down (sub/super), the cursor is moved in front (left) of the object on which the sub/superscript is being added, as opposed to the right-most end of the object, below/above the super/subscript. If anyone can think of a word which refers to subscripts and superscripts collectively, that bug report would be much more readable. :P Cheers, Dan
Re: Bug 2069: Movement out of sub/superscript works unexpectedly
Daniel Watkins wrote: If anyone can think of a word which refers to subscripts and superscripts collectively, that bug report would be much more readable. :P script insets ;-) BTW I didn't understand the report. Jürgen
Re: LyX speedup patch
On Sun, Oct 02, 2005 at 05:59:38PM +0300, Martin Vermeer wrote:
On Sun, Oct 02, 2005 at 01:26:06PM +0200, Andre Poenitz wrote:
...
So we should try hard to pass through the critical path just once. I'll
send later today a preliminary patch that folds rowBreakPoint() and
setRowWidth(), i.e. reduces this by a factor of two and gives an overall
gain of 8-12% when typing into a single long paragraph of about 1200
chars. I won't be able to take care of this patch after I send it to the
list, so I wouldn't mind if somebody took over.
Looking at your later patch, am I right in assuming that this is
orthogonal to the things that I have been playing with?
Yes.
The aim is the same: make it faster, but code is unrelated.
[Fine grained 'invalidation']
Does this sound like a plan?
Yes... as it happens I was today thinking along similar lines. But
wouldn't it be enough to just cache, e.g., the pos of row end, to
determine whether the current row content changes or not, and if not,
skip out of the rebreak and render routines? Or would that become messy?
I'd just record what happened and leave the interpretation of what needs
to be done to the actual update routine (the 'second phase'). So we have
a single point of failure when it comes to clever guessing and in that
second phase we have 'full information'.
How the information 'char was inserted' is stored is secondary. If
people feel recording line ends is enough - fine. I'd have started with
some struct { what, where, phase-of-moon }; or something as generic as
that.
Andre'
Re: [patches 13x, 14x] wrappers for ShGetFolderPath, GetLongPathName
On Sun, Oct 02, 2005 at 06:19:34PM +0100, Angus Leeming wrote: Andre Poenitz wrote: Right, but we'll need to patch our qt frontend source code to use Qt4, no? 'patch' would be a proper British understatement. 'rework' would be closer in a continental climate. Really? I've been playing with the KDVI sources recently and there the initial migration to Qt4, using the Q3ScrollView et al stuff seems almost automatic. I do not consider using the Q3X classes as 'proper port'. Using them bites only a bit later. I've ported a 40kloc test app from Qt 3.3 to 4 and spend about 30% of the initial time to create the Qt 3.3 just for porting. Of course, the more non-Qt generic stuff there is, the less porting is necessary. Anyway, porting is not really hard, it's just tedious. In other words, we should be able to manage the migration to real Qt4 so that we can address each dialog, the menubars, toolbars and the main LyX screen in isolation. Qt 4's designer does not even support mainwindows (yet, promised for 4.1...) Andre'
Re: [patch] Bug 2067 (was: Re: [Bug 2058] LyX crashes when attempting to undo matrix deletion)
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 != ) {
if (os.fragile())
os \\protect;
os s;
}
+ else
+ os ;
}
I'd think
if (os.fragile())
os \\protect;
would be needed in this case as well.
Andre'
Re: Bug 2069: Movement out of sub/superscript works unexpectedly
On Mon, Oct 03, 2005 at 06:38:26PM +0100, Daniel Watkins wrote: And now, ladies and gentlemen, we return you to your regular programming. A MathEd bug! Did I mention that I feel a bit humilitated by your recent activities? But lucky me there are a few people out there trying to cover my backside... [Never mind, though. They've been some of the best bug reports for mathed I've seen for years...] Bug 2069: Movement out of sub/superscript works unexpectedly Description: When, at the leftmost end of the sub/superscript, you press left or, at any point in the sub/superscript, you press up/down (sub/super), the cursor is moved in front (left) of the object on which the sub/superscript is being added, as opposed to the right-most end of the object, below/above the super/subscript. Ugly, isn't it... The main problem here is that up/down in math is extremely tricky to get 'right' in the general case and I rarely like work-arounds for special cases. Of course, super/subscripts already get a lot af special interest, so work-arounds for these 'special' cases are more or less in order. Just trying to explain why it is like it is... If anyone can think of a word which refers to subscripts and superscripts collectively, that bug report would be much more readable. :P In MathEd super and subscripts are handled in 'MathScriptInsets' and the term is simply 'scripts'. But that's completely ad-hoc. Andre'
Re: [patch] fix bug 2060
Am Montag, 3. Oktober 2005 15:04 schrieb Jean-Marc Lasgouttes: What I wondering is whether MathNestInset should tell the world that it is not editable when size() == 0. It is always strange to have to add these tests all over the place. I agree, but after trying to implement that I found out that the insets editable() method is not used in mathed, because all math insets except InsetFormulaMacro, MathMacroTemplate and MathHullInset use the default implementation of editable() which return NOT_EDITABLE. Or did you mean something else? But if you think it is not possible to do better, apply this and also the other one you just posted. I am going to do so unless somebody has a better idea. Georg
Re: [patch] fix bug 2060
On Mon, Oct 03, 2005 at 02:30:10PM +0200, Georg Baum wrote: Am Montag, 3. Oktober 2005 14:22 schrieb Jean-Marc Lasgouttes: Should some of these tests be asserts? If you can assure me that drawSelection() and cursorPos() don't get called for macros with 0 arguments and macros with 0 arguments are the only case of a MathNestInset, then yes. Macros with 0 arguments are the only NestInsets with 0 cells I know. But if you'd asked me yesterday I'd have sworn there are no such NestInsets at all... Andre'
Re: TOC generation and autogen.sh
Am Montag, 3. Oktober 2005 14:51 schrieb Angus Leeming:
I also note that it's an old version of automake (1.6) although
autogen.sh is currently set up to accept it.
OK, by typing
apt-get install automake1.6
update-alternatives --set automake /usr/bin/automake-1.6
I switched to automake 1.6 and tested it. The latest version of the patch
is attached. It works for me both with automake 1.6 and 1.9.
I really would like to commit that, since the current setup is broken.
Angues, Helge, Kayvan, is that working for you, too?
Georg
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/lib/doc/ChangeLog lyx-1.4-cvs/lib/doc/ChangeLog
--- lyx-1.4-clean/lib/doc/ChangeLog 2005-09-29 21:46:21.0 +0200
+++ lyx-1.4-cvs/lib/doc/ChangeLog 2005-10-03 19:19:33.322540376 +0200
@@ -1,3 +1,11 @@
+2005-10-03 Georg Baum [EMAIL PROTECTED]
+
+ * depend.py, Makefile.am: Don't use TOCs both as variable name and
+ target, because automake 1.6 complains
+ * depend.py: Don't hardcode current srcdir and builddir, use variables
+ * Makefile.am: Use install and dist hooks for TOCs because they don't
+ get built otherwise
+
2005-09-28 Georg Baum [EMAIL PROTECTED]
* doc_toc.py: make it work again with builddir == srcdir
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/lib/doc/depend.py lyx-1.4-cvs/lib/doc/depend.py
--- lyx-1.4-clean/lib/doc/depend.py 2005-09-29 21:46:23.0 +0200
+++ lyx-1.4-cvs/lib/doc/depend.py 2005-10-03 18:19:34.372663920 +0200
@@ -48,13 +48,14 @@ def main(argv):
#
# First come the rules for each xx_TOC.lyx file. Then comes the
# TOCs target, which prints all the TOC files.
- % argv[0]
+ % os.path.basename(argv[0])
# What are the languages available? And its documents?
languages = {}
srcdir = os.path.dirname(argv[0])
for file in glob(srcdir + '/*'):
-lang = lang_pattern.match(os.path.basename(file))
+file = os.path.basename(file)
+lang = lang_pattern.match(file)
if lang:
if lang.group(1) not in languages:
languages[lang.group(1)] = [file]
@@ -66,8 +67,8 @@ def main(argv):
langs.sort()
# The default language is english and doesn't need any prefix
-print 'TOC.lyx:', ('.lyx ' + srcdir + '/').join(possible_documents) + '.lyx'
-print '\tpython %s/doc_toc.py' % srcdir
+print 'TOC.lyx: $(srcdir)/' + '.lyx $(srcdir)/'.join(possible_documents) + '.lyx'
+print '\tpython $(srcdir)/doc_toc.py'
print
tocs = ['TOC.lyx']
@@ -78,15 +79,13 @@ def main(argv):
if toc_name in languages[lang]:
languages[lang].remove(toc_name)
-if srcdir + '/' + toc_name in languages[lang]:
-languages[lang].remove(srcdir + '/' + toc_name)
-print toc_name + ':', ' '.join(languages[lang])
-print '\tpython %s/doc_toc.py %s' % (srcdir, lang)
+print toc_name + ': $(srcdir)/' + ' $(srcdir)/'.join(languages[lang])
+print '\tpython $(srcdir)/doc_toc.py %s' % lang
print
# Write meta-rule to call all the other rules
-print 'TOCs =', ' '.join(tocs)
+print 'tocfiles =', ' '.join(tocs)
if __name__ == __main__:
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/lib/doc/Makefile.am lyx-1.4-cvs/lib/doc/Makefile.am
--- lyx-1.4-clean/lib/doc/Makefile.am 2005-09-29 21:46:21.0 +0200
+++ lyx-1.4-cvs/lib/doc/Makefile.am 2005-10-03 19:14:59.802121800 +0200
@@ -1,10 +1,10 @@
include $(top_srcdir)/config/common.am
-DISTCLEANFILES += LyXConfig.lyx LaTeXConfig.lyx $(TOCs)
+DISTCLEANFILES += LyXConfig.lyx LaTeXConfig.lyx $(tocfiles)
EXTRA_DIST = depend.py doc_toc.py LyXConfig.lyx.in README.Documentation $(DEPENDFILE) $(docfiles)
-docfiles = $(TOCs) \
+docfiles = \
cs_Tutorial.lyx \
Customization.lyx \
da_Intro.lyx \
@@ -70,18 +70,32 @@ doc_DATA = \
$(docfiles) \
LaTeXConfig.lyx
-DEPENDFILE = Makefile.depend
-include $(DEPENDFILE)
+DEPENDFILE = $(srcdir)/Makefile.depend
+# include $(DEPENDFILE) does not work because automake is too limited.
+include $(srcdir)/Makefile.depend
-TOCs : $(DEPENDFILE) $(TOCs)
+TOCs : $(DEPENDFILE) $(tocfiles)
@echo Made TOCs succesfully.
# Force regeneration of $(DEPENDFILE) when Makefile.am changes because
# new doc files might have been added
-$(DEPENDFILE): Makefile.am
+$(DEPENDFILE): $(srcdir)/Makefile.am $(srcdir)/depend.py
python $(srcdir)/depend.py $(DEPENDFILE)
-# Force generation of the TOC files for 'make dist'
-distdir: TOCs
+# The TOCs are not built for the install and dist targets if they don't exist
+# for some weird reason.
+# Make complains although we have rules for them in $(DEPENDFILE), so we
+# must not include the TOCs in $(docfiles) and have to use the install and
+# dist hooks below.
+dist-hook: $(tocfiles)
+ for i in $(tocfiles); \
+ do \
+ cp -p $$i $(distdir); \
+ done
+install-data-hook: $(tocfiles)
+ for i in $(tocfiles); \
+ do \
+ $(docDATA_INSTALL) $$i $(DESTDIR)$(docdir)/$$i; \
+ done
.PHONY: TOCs
diff -p -r -U 3 -X excl.tmp
Re: TOC generation and autogen.sh
Georg Baum wrote: Am Montag, 3. Oktober 2005 14:51 schrieb Angus Leeming: I also note that it's an old version of automake (1.6) although autogen.sh is currently set up to accept it. OK, by typing apt-get install automake1.6 update-alternatives --set automake /usr/bin/automake-1.6 I switched to automake 1.6 and tested it. The latest version of the patch is attached. It works for me both with automake 1.6 and 1.9. I really would like to commit that, since the current setup is broken. Angues, Helge, Kayvan, is that working for you, too? On a pristine and up to date CVS tree, everything looks fine with this patch. Angus $ cd build make maintainer-clean $ cd .. $ rm -rf autom4te.cache build $ patch -p1 TOC3.diff patching file lib/doc/depend.py patching file lib/doc/Makefile.am patching file lib/doc/Makefile.depend (I removed the ChangeLog entry because gmane mangled your email address.) $ sh ./autogen.sh Using automake (GNU automake) 1.6.3 Using autoconf (GNU Autoconf) 2.59 Locating GNU m4... /usr/bin/m4 Generate acinclude.m4... done. Building macros... . done. Building config header template... . done. Building Makefile templates... . done. Building configure... . done. Building lib/configure ... done. run ./configure ; make $ mkdir build cd build $ ../configure \ LDFLAGS='-Wl,-t' \ --with-version-suffix \ --disable-stdlib-debug \ --with-frontend='qt xforms' \ --with-qt-includes='/usr/include/qt3' $ cd lib make Making all in doc make[1]: Entering directory `/disk4/lyx/devel/build/lib/doc' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/disk4/lyx/devel/build/lib/doc' Making all in lyx2lyx make[1]: Entering directory `/disk4/lyx/devel/build/lib/lyx2lyx' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/disk4/lyx/devel/build/lib/lyx2lyx' make[1]: Entering directory `/disk4/lyx/devel/build/lib' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/disk4/lyx/devel/build/lib' $ su $ rm -rf /usr/local/share/lyx-1.4.0cvs $ make install $ ls /usr/local/share/lyx-1.4.0cvs/doc/ Customization.lyx eu_Extended.lyx no_Intro.lyx DocStyle.lyx eu_FAQ.lyxno_TOC.lyx Extended.lyx eu_Intro.lyx pl_Extended.lyx FAQ.lyx eu_TOC.lyxpl_Intro.lyx Intro.lyx eu_Tutorial.lyx pl_TOC.lyx LaTeXConfig.lyx eu_UserGuide.lyx pl_Tutorial.lyx LaTeXConfig.lyx.infr_Customization.lyx platypus.eps Reference.lyx fr_Extended.lyx pt_Intro.lyx TOC.lyx fr_FAQ.lyxpt_TOC.lyx Tutorial.lyx fr_Intro.lyx pt_Tutorial.lyx UserGuide.lyx fr_TOC.lyxro_Intro.lyx cs_TOC.lyxfr_Tutorial.lyx ro_TOC.lyx cs_Tutorial.lyx fr_UserGuide.lyx ru_FAQ.lyx da_Intro.lyx he_Intro.lyx ru_Intro.lyx da_TOC.lyxhe_TOC.lyxru_TOC.lyx de_Customization.lyx he_Tutorial.lyx ru_Tutorial.lyx de_Extended.lyx hu_Intro.lyx sk_TOC.lyx de_FAQ.lyxhu_TOC.lyxsk_Tutorial.lyx de_Intro.lyx it_Customization.lyx sk_UserGuide.lyx de_TOC.lyxit_Intro.lyx sl_Intro.lyx de_Tutorial.lyx it_TOC.lyxsl_TOC.lyx de_UserGuide.lyx it_Tutorial.lyx sl_Tutorial.lyx es_Intro.lyx it_UserGuide.lyx sv_Intro.lyx es_TOC.lyxmobius.epssv_TOC.lyx es_Tutorial.lyx nl_Intro.lyx sv_Tutorial.lyx escher-lsd.epsnl_TOC.lyx eu_Customization.lyx nl_Tutorial.lyx
MathEd bug related to 2050/60 (?)
Hey guys, I'm completely confused by which bug covers what, so I'll tell you the bug and hopefully someone will tell me what's going on. :p Summary: Arrows with curves in display incorrectly/crash LyX Any of the \hook arrows don't display correctly when typed and, when clicked upon within the Maths Editor, crash LyX. This seems similar to one of the bugs discussed, but I can't find it ATM (which worries me). I apologise if this is a stupid report, but I'm tired. :p Cheers, Dan
Re: TOC generation and autogen.sh
On Mon, Oct 03, 2005 at 07:46:38PM +0200, Georg Baum wrote: Am Montag, 3. Oktober 2005 14:51 schrieb Angus Leeming: I also note that it's an old version of automake (1.6) although autogen.sh is currently set up to accept it. OK, by typing apt-get install automake1.6 update-alternatives --set automake /usr/bin/automake-1.6 I switched to automake 1.6 and tested it. The latest version of the patch is attached. It works for me both with automake 1.6 and 1.9. I really would like to commit that, since the current setup is broken. Angues, Helge, Kayvan, is that working for you, too? Georg I can check this later today.
Latest CVS: make rpmdist fails
config.status: creating development/lyx.spec config.status: creating lib/Makefile config.status: creating lib/doc/Makefile config.status: error: cannot find input file: lib/doc/Makefile.in error: Bad exit status from /var/tmp/rpm-tmp.95005 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.95005 (%build) make: *** [rpmdist] Error 1
Re: relyx inserts spaces in tables imported from LaTeX
Jean-Marc Lasgouttes wrote:
John == John Mongan [EMAIL PROTECTED] writes:
John I believe this problem can be fixed in the BasicLyx.pm module of
John reLyX by defining each new cell to be the start of a paragraph,
John so that the subsequent Text will have it's leading white-space
John zapped. This can be accomplished as follows:
But doesn't this have some side-effects? Did you try to compare the
reLyX output with and without the patch?
I've done a little more extensive testing:
Yes, it does have side effects, but they seem to be good ones (that is,
they fix additional bugs). For instance if there's text formatting (e.g.
\textbf{} ) in the table, the current reLyx loses it for all but the
first cell. With the patch, the formatting is correctly translated.
There may be instances in which there are undesirable side effects, but
I haven't seen them in my testing.
John However, I don't begin to pretend to understand everything going
John on in reLyX, so I'm hoping someone more knowledgeable than
John myself might be able to comment on whether this fix is likely to
John cause problems elsewhere. If it does turn out to be a legitimate
John fix, I hope it might be committed for future versions.
The problem is that nobody really understand reLyX currently :( It is
slated for replacement with tex2lyx in 1.4.0.
I see. From my perspective, the patch fixes a couple of pretty nasty
formatting bugs in latex-lyx translation, and it seems likely that any
bugs it would introduce would likewise be formatting bugs and probably
less severe than the ones that are fixed. However, I understand the
resistance to change a piece of code that's poorly understood, or to
invest resources in code that's going away soon anyway.
If you decide not to officially include the patch, perhaps I'll post it
on the wiki as an unsupported possibility for people to try?
Thanks,
John
[patch] Bug 2067 (was: Re: [Bug 2058] LyX crashes when attempting to undo matrix deletion)
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 is only one remaining.
> A row with content, or the top row, will stop any more rows disappearing.
>
> Steps to reproduce:
> 1) Create 3x3 matrix.
> 2) Cursor in top-left box.
> 3) Backspace.
> 4) Undo
>
> Result:
> An empty 3x2 matrix is restored.
>
> Expected result:
> An empty 3x3 matrix is restored.
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
written for the first empty line.
Patch attached.
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 != " ") {
if (os.fragile())
os << "\\protect";
os << "" << s;
}
+ else
+ os << "";
}
Index: math_gridinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_gridinset.C,v
retrieving revision 1.168
diff -p -u -r1.168 math_gridinset.C
--- math_gridinset.C 18 Jul 2005 00:09:20 - 1.168
+++ math_gridinset.C 3 Oct 2005 07:43:51 -
@@ -975,6 +975,8 @@ void MathGridInset::write(WriteStream &
os << "\\protect";
os << "" << s;
}
+ else
+ os << "";
}
@@ -1043,7 +1045,7 @@ void MathGridInset::doDispatch(LCursor &
// FIXME: We use recordUndoInset when a change reflects more
// than one cell, because recordUndo does not work for
// multiple cells. Unfortunately this puts the cursor in front
- // of the inset after undo. This is (especilally for large
+ // of the inset after undo. This is (especially for large
// grids) annoying.
recordUndoInset(cur);
//autocorrect_ = false;
Re: Hebrew/bidi bug 1975
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> A fresh patch for bug 1975, due to the boundary changes. Martin> Bugzilla doesn't like me today, so attached. Martin> Still no external testers found... please?!? Did this ever got applied? JMarc
TOC generation and autogen.sh
Georg, I realise that others have been telling you of problems with the TOC-generation stuff that you played with recently. However, I haven't noticed any messages about autogen.sh output: HTH, Angus Building Makefile templates... . Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `TOCs' is a target; expected a variable lib/doc/Makefile.am:66: variable `TOCs' not defined Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `TOCs' is a target; expected a variable lib/doc/Makefile.am:66: variable `TOCs' not defined Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450. : `distdir' is a target; expected a variable done. Building configure...
Re: LyX speedup patch
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> Yes... as it happens I was today thinking along similar lines. Martin> But wouldn't it be enough to just cache, e.g., the pos of row Martin> end, to determine whether the current row content changes or Martin> not, and if not, skip out of the rebreak and render routines? Martin> Or would that become messy? This would mean implementing SingleRow update instead of SinglePar, right? JMarc
Re: Bug 2058: LyX crashes when attempting to undo matrix deletion
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Georg Baum wrote: >> Why don't you put the code in MathNestInset? Since backspace at the >> first position deletes the containing inset in every math inset I >> think that recordUndoInset should also be called in general. Juergen> Yes, why not (I was not aware of that feature, knowing mathed Juergen> basically from bug fixing). Patch attached. This looks OK. JMarc
Re: [patch] fix bug 2050
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> See http://bugzilla.lyx.org/show_bug.cgi?id=2050. Math mcros Georg> that contain \kern are misrendered on screen. The fix is Georg> obvious, and I could not reproduce the crash. I propose to put Georg> this in. If the crash reappears we may find out the real Georg> reason, but for now I think that it is gone. Georg> OK? OK. JMarc
Re: Hebrew/bidi bug 1975
On Mon, 2005-10-03 at 11:31 +0200, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> A fresh patch for bug 1975, due to the boundary changes. > > Martin> Bugzilla doesn't like me today, so attached. > > Martin> Still no external testers found... please?!? > > Did this ever got applied? No... hanging in my tree. - Martin signature.asc Description: This is a digitally signed message part
Re: LyX speedup patch
On Mon, 2005-10-03 at 11:38 +0200, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> Yes... as it happens I was today thinking along similar lines. > Martin> But wouldn't it be enough to just cache, e.g., the pos of row > Martin> end, to determine whether the current row content changes or > Martin> not, and if not, skip out of the rebreak and render routines? > Martin> Or would that become messy? > > This would mean implementing SingleRow update instead of SinglePar, > right? Yes, I think so. How to do it is another matter. I suspect that caching row.endpos() internally in lyxtext would be enough. - Martin signature.asc Description: This is a digitally signed message part
Re: Hebrew/bidi bug 1975
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: >> Did this ever got applied? Martin> No... hanging in my tree. So, what has to be done? testing? How confident are you? JMarc
[patch] bug 1894: Disabling of widgets broken
It came out that the problem is caused by refreshReadOnly(), called (indirectly) by Dialog::checkStatus(). refreshReadOnly disables all widgets (that are addReadOnly()'ed) in read only mode and enables all these widgets in non-read-only mode. The latter, which is necessary to switch modes, overrides the intiial disabling of certain widgets by the dialogs. The attached patch just calls the dialog's update() after all widgets have been enabled by refreshReadOnly, so that the widgets that should be disabled actually get disabled. I have tested all scenarios I could think of (non-read-only, read-only and switches between those two modes) and saw no problems. Comments? Jürgen Index: Dialog.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/Dialog.C,v retrieving revision 1.18 diff -p -u -r1.18 Dialog.C --- Dialog.C 26 Apr 2005 09:37:52 - 1.18 +++ Dialog.C 3 Oct 2005 09:57:09 - @@ -186,11 +186,17 @@ void Dialog::checkStatus() return; } + bool const readonly = kernel().isBufferReadonly(); // check whether this dialog may be active if (controller().canApply()) - bc().readOnly(kernel().isBufferReadonly()); + bc().readOnly(readonly); else bc().readOnly(true); + + // refreshReadOnly() is too generous in _enabling_ widgets + // update dialog to disable disabled widgets again + if (!readonly) + view().update(); }
Re: LyX speedup patch
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: >> This would mean implementing SingleRow update instead of >> SinglePar, right? Martin> Yes, I think so. How to do it is another matter. I suspect Martin> that caching row.endpos() internally in lyxtext would be Martin> enough. This would be almost similar to what you do with paragraph dimension caching. I guess the algorithm could be to redo the rows one by one (starting from cursor) until we find one that did not change. JMarc
Re: [patch] bug 1894: Disabling of widgets broken
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> It came out that the problem is caused by refreshReadOnly(), Juergen> called (indirectly) by Dialog::checkStatus(). refreshReadOnly Juergen> disables all widgets (that are addReadOnly()'ed) in read only Juergen> mode and enables all these widgets in non-read-only mode. The Juergen> latter, which is necessary to switch modes, overrides the Juergen> intiial disabling of certain widgets by the dialogs. Juergen> The attached patch just calls the dialog's update() after all Juergen> widgets have been enabled by refreshReadOnly, so that the Juergen> widgets that should be disabled actually get disabled. Juergen> Comments? Shouldn't the update be added inside the "if (controller().canApply())" block? The looks OK. Angus? JMarc
Re: [patch] bug 1894: Disabling of widgets broken
Juergen Spitzmueller wrote: > It came out that the problem is caused by refreshReadOnly(), called > (indirectly) by Dialog::checkStatus(). refreshReadOnly disables all > widgets (that are addReadOnly()'ed) in read only mode and enables > all these widgets in non-read-only mode. The latter, which is > necessary to switch modes, overrides the intiial disabling of > certain widgets by the dialogs. > > The attached patch just calls the dialog's update() after all > widgets have been enabled by refreshReadOnly, so that the widgets > that should be disabled actually get disabled. > > I have tested all scenarios I could think of (non-read-only, > read-only and switches between those two modes) and saw no problems. > > Comments? > > Jürgen Hi, Jürgen. Sorry I didn't manage to get back to your bugzilla query earlier. Now all is explained, I can see why this patch is needed and why it will work. The solution looks reasonable to me. -- Angus
Re: [patch] bug 1894: Disabling of widgets broken
Jean-Marc Lasgouttes wrote: > Shouldn't the update be added inside the > "if (controller().canApply())" block? I just thought about that, too. It's certainly safer, I'll do this. Jürgen
Re: [patch] bug 1894: Disabling of widgets broken
Jean-Marc Lasgouttes wrote: > Juergen> Comments? > > Shouldn't the update be added inside the > "if (controller().canApply())" block? Urgs. Probably :) Especially given that fact that view_.update() isn't needed for a read-only document. > The looks OK. Angus? -- Angus
Re: [patch] bug 1894: Disabling of widgets broken
Juergen Spitzmueller wrote:
> > Shouldn't the update be added inside the
> > "if (controller().canApply())" block?
>
> I just thought about that, too. It's certainly safer, I'll do this.
OK to apply the attached?
Jürgen
BTW this bug also applies to 1.3
Index: Dialog.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/Dialog.C,v
retrieving revision 1.18
diff -p -u -r1.18 Dialog.C
--- Dialog.C 26 Apr 2005 09:37:52 - 1.18
+++ Dialog.C 3 Oct 2005 10:31:01 -
@@ -187,9 +187,14 @@ void Dialog::checkStatus()
}
// check whether this dialog may be active
- if (controller().canApply())
- bc().readOnly(kernel().isBufferReadonly());
- else
+ if (controller().canApply()) {
+ bool const readonly = kernel().isBufferReadonly();
+ bc().readOnly(readonly);
+ // refreshReadOnly() is too generous in _enabling_ widgets
+ // update dialog to disable disabled widgets again
+ if (!readonly)
+ view().update();
+ } else
bc().readOnly(true);
}
Re: [patch] bug 1894: Disabling of widgets broken
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Jean-Marc Lasgouttes wrote: >> Shouldn't the update be added inside the "if >> (controller().canApply())" block? Juergen> I just thought about that, too. It's certainly safer, I'll do Juergen> this. OK. You can apply then. JMarc
Re: LyX speedup patch
On Mon, 2005-10-03 at 12:16 +0200, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > >> This would mean implementing SingleRow update instead of > >> SinglePar, right? > > Martin> Yes, I think so. How to do it is another matter. I suspect > Martin> that caching row.endpos() internally in lyxtext would be > Martin> enough. > > This would be almost similar to what you do with paragraph dimension > caching. I guess the algorithm could be to redo the rows one by one > (starting from cursor) until we find one that did not change. Precisely. The place would be in redoParagraph, the do...while loop on z. I wonder if this is enough, or if we should then also look at the rendering side of things. Probably. - Martin signature.asc Description: This is a digitally signed message part
Re: [patch] bug 1894: Disabling of widgets broken
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> BTW this bug also applies to 1.3 You can also apply to 1.3.x, then (after some basic testing, of course :) JMarc
[PATCH] fix macro type with math-macro
Found this while investigating 2050/2060: when creating a macro with "math-macro aa", the type is set to "" instead of "newcommand". It is an obvious typo in the code, so I'll just commit. JMarc Index: src/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v retrieving revision 1.2293 diff -u -p -r1.2293 ChangeLog --- src/ChangeLog 28 Sep 2005 15:02:45 - 1.2293 +++ src/ChangeLog 3 Oct 2005 10:50:52 - @@ -1,3 +1,8 @@ +2005-10-03 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> + + * text3.C (dispatch): when invoking LFUN_MATH_MACRO with no type + argument, use "newcommand". + 2005-09-28 Jürgen Spitzmüller <[EMAIL PROTECTED]> * cursor.C (setSelection): do not open collapsable insets; Index: src/text3.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v retrieving revision 1.308 diff -u -p -r1.308 text3.C --- src/text3.C 27 Sep 2005 08:42:28 - 1.308 +++ src/text3.C 3 Oct 2005 10:50:52 - @@ -1254,7 +1254,7 @@ void LyXText::dispatch(LCursor & cur, Fu int const nargs = s1.empty() ? 0 : convert(s1); string const s2 = token(s, ' ', 2); string const type = s2.empty() ? "newcommand" : s2; - cur.insert(new MathMacroTemplate(token(s, ' ', 0), nargs, s2)); + cur.insert(new MathMacroTemplate(token(s, ' ', 0), nargs, type)); //cur.nextInset()->edit(cur, true); } break;
Re: [PATCH] fix macro type with math-macro
Jean-Marc Lasgouttes wrote: > Found this while investigating 2050/2060: when creating a macro with > "math-macro aa", the type is set to "" instead of "newcommand". > > It is an obvious typo in the code, so I'll just commit. It may be an obvious typo, but it looks to me like it should be MathMacroTemplate itself that decides what to do with s2. Shouldn't the whole string const type = s2.empty() ? "newcommand" : s2; be moved into the MathMacroTemplate constructor? -- Angus
Re: [patch] bug 1894: Disabling of widgets broken
Jean-Marc Lasgouttes wrote: > Juergen> BTW this bug also applies to 1.3 > > You can also apply to 1.3.x, then (after some basic testing, of course Hm, things look quite a bit different there. I have to take time and look how 1.3 does what checkStatus does in 1.4 Jürgen
Re: Hebrew/bidi bug 1975
On Mon, 2005-10-03 at 12:08 +0200, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > >> Did this ever got applied? > > Martin> No... hanging in my tree. > > So, what has to be done? testing? How confident are you? Pretty confident, as it appears that RtL is connected to language and completely decoupled from font. That makes it possible to test without having Hebrew fonts installed... still I would have appreciated a Hebrew tester. - Martin signature.asc Description: This is a digitally signed message part
Re: Hebrew/bidi bug 1975
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> On Mon, 2005-10-03 at 12:08 +0200, Jean-Marc Lasgouttes wrote: >> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: >> >> >> Did this ever got applied? >> Martin> No... hanging in my tree. >> So, what has to be done? testing? How confident are you? Martin> Pretty confident, as it appears that RtL is connected to Martin> language and completely decoupled from font. That makes it Martin> possible to test without having Hebrew fonts installed... Martin> still I would have appreciated a Hebrew tester. Since it only affects RtL, I'd say that you should apply it. JMarc
Re: [PATCH] fix macro type with math-macro
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: >> Found this while investigating 2050/2060: when creating a macro >> with "math-macro aa", the type is set to "" instead of >> "newcommand". >> >> It is an obvious typo in the code, so I'll just commit. Angus> It may be an obvious typo, but it looks to me like it should be Angus> MathMacroTemplate itself that decides what to do with s2. Angus> Shouldn't the whole string const type = s2.empty() ? Angus> "newcommand" : s2; be moved into the MathMacroTemplate Angus> constructor? Yes, probably. I decided to make a minimal change, since there were so many things I wanted to rewrite in there :) JMarc
Re: Hebrew/bidi bug 1975
On Mon, 2005-10-03 at 14:00 +0200, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> On Mon, 2005-10-03 at 12:08 +0200, Jean-Marc Lasgouttes wrote: > >> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > >> > >> >> Did this ever got applied? > >> > Martin> No... hanging in my tree. > >> So, what has to be done? testing? How confident are you? > > Martin> Pretty confident, as it appears that RtL is connected to > Martin> language and completely decoupled from font. That makes it > Martin> possible to test without having Hebrew fonts installed... > Martin> still I would have appreciated a Hebrew tester. > > Since it only affects RtL, I'd say that you should apply it. Done. Let's hope we get some testing ;-) - Martin signature.asc Description: This is a digitally signed message part
Re: TOC generation and autogen.sh
Am Montag, 3. Oktober 2005 11:37 schrieb Angus Leeming: > Use of uninitialized value in concatenation (.) or string > at /usr/bin/automake line 8450. > : `TOCs' is a target; expected a variable > lib/doc/Makefile.am:66: variable `TOCs' not defined > Use of uninitialized value in concatenation (.) or string > at /usr/bin/automake line 8450. > : `TOCs' is a target; expected a variable > lib/doc/Makefile.am:66: variable `TOCs' not defined > Use of uninitialized value in concatenation (.) or string > at /usr/bin/automake line 8450. > : `distdir' is a target; expected a variable > done. > Building configure... I don't get this. Do you have my patch TOC2.diff from saturday applied? If yes, does it help to rename the TOCs target (I have both a variable TOCs and a target TOCs. Maybe automake is too stupid to handle that?) Georg
Re: [patch] fix bug 2060
Am Sonntag, 2. Oktober 2005 23:58 schrieb Angus Leeming:
> I can confirm the crash but can also supply some debug info.
Thanks. The reason for the crash is the same as # 2060: MathNestInsets may
have 0 cells.
Fix attached. OK to commit? And the fix for # 2060?
Georg
PS: Daniel, many thanks for the bug reports. They are really useful.
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/mathed/ChangeLog lyx-1.4-cvs/src/mathed/ChangeLog
--- lyx-1.4-clean/src/mathed/ChangeLog 2005-10-03 13:39:19.0 +0200
+++ lyx-1.4-cvs/src/mathed/ChangeLog 2005-10-03 13:56:38.197723448 +0200
@@ -1,3 +1,8 @@
+2005-10-03 Georg Baum <[EMAIL PROTECTED]>
+
+ * math_nestinset.C (doDispatch): fix crash when inserting math macros
+ with 0 arguments
+
2005-10-02 Georg Baum <[EMAIL PROTECTED]>
* math_kerninset.C (write): write width, not 0 (fixes bug 2050)
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/mathed/math_nestinset.C lyx-1.4-cvs/src/mathed/math_nestinset.C
--- lyx-1.4-clean/src/mathed/math_nestinset.C 2005-10-03 13:12:07.0 +0200
+++ lyx-1.4-cvs/src/mathed/math_nestinset.C 2005-10-03 13:55:49.664101680 +0200
@@ -861,7 +872,10 @@ void MathNestInset::doDispatch(LCursor &
int cell(0);
if (cmd.argument == "\\root")
cell = 1;
- if (ar.size() == 1 && (ar[0].nucleus()->asNestInset())) {
+ // math macros are nest insets and may have 0 cells.
+ // handleNest would crash in this case.
+ if (ar.size() == 1 && (ar[0].nucleus()->asNestInset()) &&
+ ar[0].nucleus()->nargs() > cell) {
cur.handleNest(ar[0], cell);
} else
cur.niceInsert(cmd.argument);
Re: [patch] Bug 2067 (was: Re: [Bug 2058] LyX crashes when attempting to undo matrix deletion)
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 > written for the first empty line. > > Patch attached. > > Does this look sensible? 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 row if it follows a hline), but not in MathGridInset. I currently have no time, but might think of a solution later. Georg
Re: [patch] fix bug 2060
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> See http://bugzilla.lyx.org/show_bug.cgi?id=2060. The problem Georg> is that macros with no arguments are stored as a MathNestInset Georg> with 0 cells, and that MathNestInset::editXY() assumes at least Georg> one cell. I fixed that and added two more checks for 0 cells Georg> which I think are necessary. Georg> OK to commit? Should some of these tests be asserts? Otherwise, the main fix in the patch looks good. JMarc
Re: Bug 2057: Delete key acting unexpectedly in MathEd
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Jean-Marc Lasgouttes wrote: >>> Yes, we shall remove >>> >>> cmd = FuncRequest(LFUN_FINISHED_LEFT); >>> cur.undispatched(); Juergen> OK. Do you happen to have a patch in hand? Jean-Marc> OK, you win :) Jean-Marc> This fixes the leaving of inset, and also the selection of Jean-Marc> not-so-small atoms. I committed it. JMarc
Re: [patch] fix bug 2060
Am Montag, 3. Oktober 2005 14:22 schrieb Jean-Marc Lasgouttes: > Should some of these tests be asserts? If you can assure me that drawSelection() and cursorPos() don't get called for macros with 0 arguments and macros with 0 arguments are the only case of a MathNestInset, then yes. Otherwise we need the real test. Georg
Re: relyx inserts spaces in tables imported from LaTeX
> "John" == John Mongan <[EMAIL PROTECTED]> writes: John> I believe this problem can be fixed in the BasicLyx.pm module of John> reLyX by defining each new cell to be the start of a paragraph, John> so that the subsequent Text will have it's leading white-space John> zapped. This can be accomplished as follows: But doesn't this have some side-effects? Did you try to compare the reLyX output with and without the patch? John> However, I don't begin to pretend to understand everything going John> on in reLyX, so I'm hoping someone more knowledgeable than John> myself might be able to comment on whether this fix is likely to John> cause problems elsewhere. If it does turn out to be a legitimate John> fix, I hope it might be committed for future versions. The problem is that nobody really understand reLyX currently :( It is slated for replacement with tex2lyx in 1.4.0. JMarc
Re: CVS lyx and noweb2lyx?
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Jean-Marc Lasgouttes wrote: >> We should see what reLyX did and port that to tex2lyx, then. Georg> I did that (at least partially). It works well with the example Georg> file. Georg> Is it OK to apply? The use of the tex parser is indeed a bit rude :) But I see that what is done for verbatim is not really better. Georg> I am not sure if I got all noweb features that noweb2lyx could Georg> convert. Kayvan, could you please check whether something is Georg> missing? Kayvan? JMarc
Re: [patch] Bug 2067 (was: Re: [Bug 2058] LyX crashes when attempting to undo matrix deletion)
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 row if it follows a hline), but not in > MathGridInset. I currently have no time, but might think of a solution > later. But this patch addresses the first row, not the last. Are you sure this is related? Jürgen
Re: [patch] fix bug 2060
Georg Baum wrote: > PS: Daniel, many thanks for the bug reports. They are really useful. I have to second that. Jürgen
Re: TOC generation and autogen.sh
Georg Baum wrote: > Am Montag, 3. Oktober 2005 11:37 schrieb Angus Leeming: > >> Use of uninitialized value in concatenation (.) or string >> at /usr/bin/automake line 8450. >> : `TOCs' is a target; expected a variable >> lib/doc/Makefile.am:66: variable `TOCs' not defined >> Use of uninitialized value in concatenation (.) or string >> at /usr/bin/automake line 8450. >> : `TOCs' is a target; expected a variable >> lib/doc/Makefile.am:66: variable `TOCs' not defined >> Use of uninitialized value in concatenation (.) or string >> at /usr/bin/automake line 8450. >> : `distdir' is a target; expected a variable >> done. >> Building configure... > > I don't get this. Do you have my patch TOC2.diff from saturday > applied? No. I have a pristine CVS tree. > If yes, does it help to rename the TOCs target (I have both > a variable TOCs and a target TOCs. Maybe automake is too stupid to > handle that?) I also note that it's an old version of automake (1.6) although autogen.sh is currently set up to accept it. -- Angus
Re: [patch] fix bug 2060
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Am Montag, 3. Oktober 2005 14:22 schrieb Jean-Marc Lasgouttes: >> Should some of these tests be asserts? Georg> If you can assure me that drawSelection() and cursorPos() don't Georg> get called for macros with 0 arguments and macros with 0 Georg> arguments are the only case of a MathNestInset, then yes. Georg> Otherwise we need the real test. What I wondering is whether MathNestInset should tell the world that it is not editable when size() == 0. It is always strange to have to add these tests all over the place. But if you think it is not possible to do better, apply this and also the other one you just posted. JMarc
[PATCH] bug 2063: Spellcheck doesn't check word containing the cursor
Here is a simple fix. Instead of going forward to put the cursor at
beginning of next word, we go backward to the beginning of current
word.
Bennett, please test.
JMarc
Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.498
diff -u -p -r1.498 ChangeLog
--- src/frontends/controllers/ChangeLog 3 Oct 2005 10:37:28 - 1.498
+++ src/frontends/controllers/ChangeLog 3 Oct 2005 13:48:23 -
@@ -1,3 +1,8 @@
+2005-10-03 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * ControlSpellchecker.C (check): make sure that word at cursor
+ position is checked too. (bug 2063)
+
2005-10-03 Jürgen Spitzmüller <[EMAIL PROTECTED]>
* Dialog.C (checkStatus): update dialog after checkReadOnly has
Index: src/frontends/controllers/ControlSpellchecker.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlSpellchecker.C,v
retrieving revision 1.85
diff -u -p -r1.85 ControlSpellchecker.C
--- src/frontends/controllers/ControlSpellchecker.C 8 Sep 2005 09:20:14 - 1.85
+++ src/frontends/controllers/ControlSpellchecker.C 3 Oct 2005 13:48:23 -
@@ -190,6 +190,9 @@ void ControlSpellchecker::check()
SpellBase::Result res = SpellBase::OK;
DocIterator cur = kernel().bufferview()->cursor();
+ while (cur && cur.pos() && isLetter(cur)) {
+ cur.backwardPos();
+ }
ptrdiff_t start = 0, total = 0;
DocIterator it = DocIterator(kernel().buffer().inset());
@@ -198,9 +201,6 @@ void ControlSpellchecker::check()
for (total = start; it; it.forwardPos())
++total;
-
- for (; cur && cur.pos() && isLetter(cur); cur.forwardPos())
- ++start;
BufferParams & bufferparams = kernel().buffer().params();
exitEarly_ = false;
Re: [PATCH] bug 2063: Spellcheck doesn't check word containing the cursor
On Oct 3, 2005, at 9:53 AM, Jean-Marc Lasgouttes wrote: Here is a simple fix. Instead of going forward to put the cursor at beginning of next word, we go backward to the beginning of current word. Bennett, please test. Works for me. Bennett
