[PATCH] small glue length cleanup
look OK ?
Index: lyxgluelength.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxgluelength.C,v
retrieving revision 1.4
diff -u -r1.4 lyxgluelength.C
--- lyxgluelength.C 21 Mar 2002 17:25:14 - 1.4
+++ lyxgluelength.C 8 Aug 2002 20:09:19 -
-41,52 +41,48
{
ostringstream buffer;
- if (!plus_.zero())
- if (!minus_.zero())
- if (len_.unit() == plus_.unit() len_.unit() ==
minus_.unit())
- if (plus_.value() == minus_.value())
- buffer len_.value() +-
- plus_.value()
unit_name[len_.unit()];
- else
- buffer len_.value()
- '+' plus_.value()
- '-' minus_.value()
- unit_name[len_.unit()];
- else
- if (plus_.unit() == minus_.unit()
-plus_.value() == minus_.value())
- buffer len_.value()
unit_name[len_.unit()]
- +- plus_.value()
- unit_name[plus_.unit()];
-
- else
- buffer len_.value()
unit_name[len_.unit()]
- '+' plus_.value()
- unit_name[plus_.unit()]
- '-' minus_.value()
- unit_name[minus_.unit()];
- else
- if (len_.unit() == plus_.unit())
- buffer len_.value() '+' plus_.value()
- unit_name[len_.unit()];
- else
- buffer len_.value() unit_name[len_.unit()]
- '+' plus_.value()
- unit_name[plus_.unit()];
-
- else
- if (!minus_.zero())
- if (len_.unit() == minus_.unit())
- buffer len_.value() '-' minus_.value()
- unit_name[len_.unit()];
-
- else
- buffer len_.value() unit_name[len_.unit()]
- '-' minus_.value()
- unit_name[minus_.unit()];
- else
- buffer len_.value() unit_name[len_.unit()];
+ buffer len_.value();
+ if (plus_.zero() minus_.zero()) {
+ buffer unit_name[len_.unit()];
+ return buffer.str().c_str();
+ }
+
+ // just len and plus
+ if (minus_.zero()) {
+ if (len_.unit() == plus_.unit())
+ buffer unit_name[len_.unit()];
+ buffer + plus_.value();
+ buffer unit_name[plus_.unit()];
+ return buffer.str().c_str();
+ }
+
+ // just len and minus
+ if (plus_.zero()) {
+ if (len_.unit() == minus_.unit())
+ buffer unit_name[len_.unit()];
+ buffer - minus_.value();
+ buffer unit_name[minus_.unit()];
+ return buffer.str().c_str();
+ }
+
+ // ok, len, plus AND minus
+
+ // len+-
+ if (minus_ == plus_) {
+ if (len_.unit() != minus_.unit())
+ buffer unit_name[len_.unit()];
+ buffer +- minus_.value();
+ buffer unit_name[minus_.unit()];
+ return buffer.str().c_str();
+ }
+
+ // this is so rare a case, why bother minimising units ?
+
+ buffer unit_name[len_.unit()];
+ buffer + plus_.value() unit_name[plus_.unit()];
+ buffer - minus_.value() unit_name[minus_.unit()];
+
return buffer.str().c_str();
}
-95,25 +91,12
{
ostringstream buffer;
+ buffer len_.value() unit_name[len_.unit()];
+
if (!plus_.zero())
- if (!minus_.zero())
- buffer len_.value() unit_name[len_.unit()]
-plus
- plus_.value() unit_name[plus_.unit()]
-minus
- minus_.value() unit_name[minus_.unit()];
- else
- buffer len_.value() unit_name[len_.unit()]
-plus
- plus_.value() unit_name[plus_.unit()];
- else
- if
[PATCH] tex_code_break_column cruft
looks like there is no need for this at all. OK ?
regards
john
Index: buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.363
diff -u -r1.363 buffer.C
--- buffer.C7 Aug 2002 23:43:36 - 1.363
+++ buffer.C8 Aug 2002 21:00:44 -
-145,9 +145,6
} // namespace anon
-extern int tex_code_break_column;
-
-
Buffer::Buffer(string const file, bool ronly)
: paragraph(0), niceFile(true), lyx_clean(true), bak_clean(true),
unnamed(false), dep_clean(0), read_only(ronly),
-2165,8 +2162,6
{
niceFile = nice; // this will be used by Insetincludes.
- tex_code_break_column = lyxrc.ascii_linelen;
-
// validate the buffer.
lyxerr[Debug::LATEX]Validating buffer... endl;
LaTeXFeatures features(params);
-2191,9 +2186,7
// usual is \batchmode and has a
// special input@path to allow the including of figures
// with either \input or \includegraphics (what figinsets do).
- // batchmode is not set if there is a tex_code_break_column.
- // In this case somebody is interested in the generated LaTeX,
- // so this is OK. input@path is set when the actual parameter
+ // input@path is set when the actual parameter
// original_path is set. This is done for usual tex-file, but not
// for nice-latex-file. (Matthias 250696)
if (!only_body) {
-2630,12 +2623,6
// Just to be sure. (Asger)
texrow.newline();
-
- // tex_code_break_column's value is used to decide
- // if we are in batchmode or not (within mathed_write()
- // in math_write.C) so we must set it to a non-zero
- // value when we leave otherwise we save incorrect .lyx files.
- tex_code_break_column = lyxrc.ascii_linelen;
lyxerr[Debug::INFO] Finished making latex file. endl;
lyxerr[Debug::INFO] Row count was texrow.rows()-1 . endl;
Index: paragraph.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph.C,v
retrieving revision 1.214
diff -u -r1.214 paragraph.C
--- paragraph.C 7 Aug 2002 16:31:45 - 1.214
+++ paragraph.C 8 Aug 2002 21:00:50 -
-54,7 +54,6
using lyx::pos_type;
-int tex_code_break_column = 72; // needs non-zero initialization. set later.
// this is a bad idea, but how can Paragraph find its buffer to get
// parameters? (JMarc)
-1188,7 +1187,7
texrow.newline();
}
- if (tex_code_break_column style-isCommand()) {
+ if (style-isCommand()) {
os '\n';
texrow.newline();
}
Index: paragraph_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph_pimpl.C,v
retrieving revision 1.39
diff -u -r1.39 paragraph_pimpl.C
--- paragraph_pimpl.C 23 Jul 2002 21:03:37 - 1.39
+++ paragraph_pimpl.C 8 Aug 2002 21:00:52 -
-31,9 +31,6
using std::upper_bound;
using std::lower_bound;
-extern int tex_code_break_column;
-
-
// Initialize static member.
ShareContainerLyXFont Paragraph::Pimpl::FontTable::container;
// Initialization of the counter for the paragraph id's,
-249,7 +246,7
LyXLayout const style)
{
if (style.pass_thru) return;
- if (column tex_code_break_column
+ if (column lyxrc.ascii_linelen
i
getChar(i - 1) != ' '
(i size() - 1)
-263,13 +260,7
|| getChar(i - 1) == '?'
|| getChar(i - 1) == ':'
|| getChar(i - 1) == '!'))) {
- if (tex_code_break_column == 0) {
- // in batchmode we need LaTeX to still
- // see it as a space not as an extra '\n'
- os %\n;
- } else {
- os '\n';
- }
+ os '\n';
texrow.newline();
texrow.start(owner_, i + 1);
column = 0;
Re: [PATCH] tex_code_break_column cruft
John Levon [EMAIL PROTECTED] writes: | looks like there is no need for this at all. OK ? To me? yes. -- Lgb
Buttons in BibTeX Database dialog
Hi, I think it would be better to streamline the BibTeX Database dialog with other dialogs by using the default buttons at the bottom of the dialog: [Restore] [OK] [Apply] [Close] The [Choose] button should then go. I suggest: --- Database: [___] [Browse] Style:[___] [Browse] Choose Style from list: +---+ | | [Update List] | | +---+ [Restore] [OK] [Apply] [Close] --- Regards, Rob.
INHERIT_LANGUAGE
what's the situation here ? john -- It is unbecoming for young men to utter maxims. - Aristotle
lyx 0.10.7
OK, I am very unable to sleep and I got bored so I thought I'd get this working. What fun ... tables really sucked then, didn't they ? I see it had a feature we would really like though : a context menu on the table. Some of it almost works with current xforms, which is funny. Actually I prefer the colour scheme too Other things I much prefer about lyx 0.10.7 : root lyx-0.10.7 151 time make ... real1m5.076s user0m59.610s sys 0m3.640s root lyx-0.10.7 151 ls -l lyx -rwxrwxr-x1 root root 2836926 Aug 9 04:37 lyx root lyx-0.10.7 154 wc -l *.[Ch] | grep total 51103 total In fact, I think it's a much better starting point. Who is with me ? More seriously, it's pretty amazing to see where Lars, JMarc et al have managed to take it in 7 years ... john -- It is unbecoming for young men to utter maxims. - Aristotle
Re: lyx 0.10.7
On Fri, 9 Aug 2002, John Levon wrote: OK, I am very unable to sleep and I got bored so I thought I'd get this working. What fun ... tables really sucked then, didn't they ? I see it had a feature we would really like though : a context menu on the table. I must have missed that one... Some of it almost works with current xforms, which is funny. Actually I prefer the colour scheme too I thought it the most hideously ugly thing I had ever seen -- just one more reason why I started using the 0.11.x development series. Much too dark and gloomy looking. Other things I much prefer about lyx 0.10.7 : root lyx-0.10.7 151 time make ... real1m5.076s user0m59.610s sys 0m3.640s root lyx-0.10.7 151 ls -l lyx -rwxrwxr-x1 root root 2836926 Aug 9 04:37 lyx root lyx-0.10.7 154 wc -l *.[Ch] | grep total 51103 total In fact, I think it's a much better starting point. Who is with me ? Ah yes those were the days. Of course back then (6 years ago) the compile times were longer than you measured because the lucky ones were compiling on P-100s instead of PIII-800s (or better). Actually, I've noticed something disturbing of late: My dual overclocked Celeron-578MHz (93MHz FSB) with 128MB takes the same amount of time to compile 1.2.1cvs as the PIII-464 (103MHz FSB) with 384MB at uni (21 minutes 30 seconds). The dually used to be at least twice as fast but changes to gcc (newer versions are slower it seems) and growing complexity of code means more RAM the better. (Maybe newer kernel also has detrimental effect since PIII runs 2.2.20 and Cellies run 2.4.18) More seriously, it's pretty amazing to see where Lars, JMarc et al have managed to take it in 7 years ... Yeah that's for sure. And if you take out two years (nearly three) for the abandoned lyx tree it sounds even better. Allan. (ARRae)
Re: lyx 0.10.7
On Fri, Aug 09, 2002 at 02:10:18PM +1000, Allan Rae wrote: I thought it the most hideously ugly thing I had ever seen -- just one more reason why I started using the 0.11.x development series. Much too dark and gloomy looking. I mean the selection colour and the greyed out below-document colour. They're lighter than they are now. Ah yes those were the days. Of course back then (6 years ago) the compile times were longer than you measured because the lucky ones were compiling on P-100s instead of PIII-800s (or better). too true :) overclocked Celeron-578MHz (93MHz FSB) with 128MB takes the same amount of time to compile 1.2.1cvs as the PIII-464 (103MHz FSB) with 384MB at uni (21 minutes 30 seconds). The dually used to be at least Luckily I bought half a gig during the trough in RAM prices so I never even touch swap. More seriously, it's pretty amazing to see where Lars, JMarc et al have managed to take it in 7 years ... Yeah that's for sure. And if you take out two years (nearly three) for the abandoned lyx tree it sounds even better. two years ? ouch :) current lyx is worth 4 million more USD than 0.10.7 too. regards john -- It is unbecoming for young men to utter maxims. - Aristotle
Re: nasty eqns lead to crash
On Thu, Aug 08, 2002 at 07:15:23PM +0100, John Levon wrote:
==9208== Conditional jump or move depends on uninitialised value(s)
==9208==at 0x40480B95: ostream::operator(int) (in
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so)
==9208==by 0x8163A63: {anonymous}::initSymbols(void) (math_factory.C:154)
==9208==by 0x8163B04: initMath(void) (math_factory.C:167)
==9208==by 0x814B07A: InsetFormulaBase::InsetFormulaBase(void)
(formulabase.C:101)
Andre ? Martin ?
The initMath code is correct.
clicking on a formula :
==9208== Conditional jump or move depends on uninitialised value(s)
==9208==at 0x817141A: MathIterator::operator++(void) (math_iterator.C:100)
==9208==by 0x8155088: MathCursor::bruteFind(int, int, int, int, int, int)
(math_cursor.C:1164)
==9208==by 0x815244B: MathCursor::setPos(int, int) (math_cursor.C:283)
==9208==by 0x814B958: InsetFormulaBase::insetButtonPress(BufferView *, int, int,
mouse_button::state) (formulabase.C:347)
Andre ?
I can't see anything wrong here, either.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: Support for LyX in design recovery tool?
On Thu, 8 Aug 2002 11:05, you wrote:
If you get round to making a detailed step-by-step of what needs doing
(a preliminary patch ?) I'll be glad to look further
Hi,
I looked into getting rid of cursor blinking for the design recovery tool.
(This makes it easier to track the cursor from screenshots.) Apparently,
it's not easy to do since every inset has its own cursor blinking code, some
of which is not trivial (e.g., tabular inset).
I tried making the following change in BufferView_pimpl.C at the end of
of the void BufferView::Pimpl::cursorToggle() method:
// change toggle calls to show calls
if (!bv_-theLockingInset()) {
bv_-showCursor(); // instead of toggle
} else {
bv_-theLockingInset()-showInsetCursor(bv_); // instead of toggle
}
cursor_timeout.restart(); // as before
}
This works for the normal cursor and most but not all inset cursors. In
particular, it doesn't work for the tabular inset. Apparently, some
non-trivial work is being done in its toggle method.
BTW, getting rid of the cursor timeout doesn't work since in some cases the
cursor is not shown at all unless it is toggled from a timeout.
Also, I tried changing the cursor color using the dialog in the GUI. (Again,
a unique cursor color makes it easier to track the cursor from screenshots.)
For some reason, the cursor color changes were always ignored (lyx 1.2).
The color sliders also had some problems. For example, I couldn't pick
254 for red; it only gave me 253 or 255. Perhaps there is a way to explicitly
specify RGB values from the startup file?
Amir
regards
john
--
It is unbecoming for young men to utter maxims.
- Aristotle
Re: lyx 0.10.7
On Fri, Aug 09, 2002 at 04:46:47AM +0100, John Levon wrote: Other things I much prefer about lyx 0.10.7 : root lyx-0.10.7 151 time make ... real1m5.076s user0m59.610s sys 0m3.640s root lyx-0.10.7 151 ls -l lyx -rwxrwxr-x1 root root 2836926 Aug 9 04:37 lyx root lyx-0.10.7 154 wc -l *.[Ch] | grep total 51103 total Waah... open wounds... More seriously, it's pretty amazing to see where Lars, JMarc et al have managed to take it in 7 years ... 'Amazing' is an interesting word ;-} Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
[PATCH] small glue length cleanup
look OK ?
Index: lyxgluelength.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxgluelength.C,v
retrieving revision 1.4
diff -u -r1.4 lyxgluelength.C
--- lyxgluelength.C 21 Mar 2002 17:25:14 - 1.4
+++ lyxgluelength.C 8 Aug 2002 20:09:19 -
@@ -41,52 +41,48 @@
{
ostringstream buffer;
- if (!plus_.zero())
- if (!minus_.zero())
- if (len_.unit() == plus_.unit() && len_.unit() ==
minus_.unit())
- if (plus_.value() == minus_.value())
- buffer << len_.value() << "+-"
- << plus_.value() <<
unit_name[len_.unit()];
- else
- buffer << len_.value()
- << '+' << plus_.value()
- << '-' << minus_.value()
- << unit_name[len_.unit()];
- else
- if (plus_.unit() == minus_.unit()
- && plus_.value() == minus_.value())
- buffer << len_.value() <<
unit_name[len_.unit()]
- << "+-" << plus_.value()
- << unit_name[plus_.unit()];
-
- else
- buffer << len_.value() <<
unit_name[len_.unit()]
- << '+' << plus_.value()
- << unit_name[plus_.unit()]
- << '-' << minus_.value()
- << unit_name[minus_.unit()];
- else
- if (len_.unit() == plus_.unit())
- buffer << len_.value() << '+' << plus_.value()
- << unit_name[len_.unit()];
- else
- buffer << len_.value() << unit_name[len_.unit()]
- << '+' << plus_.value()
- << unit_name[plus_.unit()];
-
- else
- if (!minus_.zero())
- if (len_.unit() == minus_.unit())
- buffer << len_.value() << '-' << minus_.value()
- << unit_name[len_.unit()];
-
- else
- buffer << len_.value() << unit_name[len_.unit()]
- << '-' << minus_.value()
- << unit_name[minus_.unit()];
- else
- buffer << len_.value() << unit_name[len_.unit()];
+ buffer << len_.value();
+ if (plus_.zero() && minus_.zero()) {
+ buffer << unit_name[len_.unit()];
+ return buffer.str().c_str();
+ }
+
+ // just len and plus
+ if (minus_.zero()) {
+ if (len_.unit() == plus_.unit())
+ buffer << unit_name[len_.unit()];
+ buffer << "+" << plus_.value();
+ buffer << unit_name[plus_.unit()];
+ return buffer.str().c_str();
+ }
+
+ // just len and minus
+ if (plus_.zero()) {
+ if (len_.unit() == minus_.unit())
+ buffer << unit_name[len_.unit()];
+ buffer << "-" << minus_.value();
+ buffer << unit_name[minus_.unit()];
+ return buffer.str().c_str();
+ }
+
+ // ok, len, plus AND minus
+
+ // len+-
+ if (minus_ == plus_) {
+ if (len_.unit() != minus_.unit())
+ buffer << unit_name[len_.unit()];
+ buffer << "+-" << minus_.value();
+ buffer << unit_name[minus_.unit()];
+ return buffer.str().c_str();
+ }
+
+ // this is so rare a case, why bother minimising units ?
+
+ buffer << unit_name[len_.unit()];
+ buffer << "+" << plus_.value() << unit_name[plus_.unit()];
+ buffer << "-" << minus_.value() << unit_name[minus_.unit()];
+
return buffer.str().c_str();
}
@@ -95,25 +91,12 @@
{
ostringstream buffer;
+ buffer << len_.value() << unit_name[len_.unit()];
+
if (!plus_.zero())
- if (!minus_.zero())
- buffer << len_.value() << unit_name[len_.unit()]
- << " plus "
- << plus_.value() << unit_name[plus_.unit()]
- << " minus "
- << minus_.value() << unit_name[minus_.unit()];
- else
- buffer <<
[PATCH] tex_code_break_column cruft
looks like there is no need for this at all. OK ?
regards
john
Index: buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.363
diff -u -r1.363 buffer.C
--- buffer.C7 Aug 2002 23:43:36 - 1.363
+++ buffer.C8 Aug 2002 21:00:44 -
@@ -145,9 +145,6 @@
} // namespace anon
-extern int tex_code_break_column;
-
-
Buffer::Buffer(string const & file, bool ronly)
: paragraph(0), niceFile(true), lyx_clean(true), bak_clean(true),
unnamed(false), dep_clean(0), read_only(ronly),
@@ -2165,8 +2162,6 @@
{
niceFile = nice; // this will be used by Insetincludes.
- tex_code_break_column = lyxrc.ascii_linelen;
-
// validate the buffer.
lyxerr[Debug::LATEX] << " Validating buffer..." << endl;
LaTeXFeatures features(params);
@@ -2191,9 +2186,7 @@
// usual is \batchmode and has a
// special input@path to allow the including of figures
// with either \input or \includegraphics (what figinsets do).
- // batchmode is not set if there is a tex_code_break_column.
- // In this case somebody is interested in the generated LaTeX,
- // so this is OK. input@path is set when the actual parameter
+ // input@path is set when the actual parameter
// original_path is set. This is done for usual tex-file, but not
// for nice-latex-file. (Matthias 250696)
if (!only_body) {
@@ -2630,12 +2623,6 @@
// Just to be sure. (Asger)
texrow.newline();
-
- // tex_code_break_column's value is used to decide
- // if we are in batchmode or not (within mathed_write()
- // in math_write.C) so we must set it to a non-zero
- // value when we leave otherwise we save incorrect .lyx files.
- tex_code_break_column = lyxrc.ascii_linelen;
lyxerr[Debug::INFO] << "Finished making latex file." << endl;
lyxerr[Debug::INFO] << "Row count was " << texrow.rows()-1 << "." << endl;
Index: paragraph.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph.C,v
retrieving revision 1.214
diff -u -r1.214 paragraph.C
--- paragraph.C 7 Aug 2002 16:31:45 - 1.214
+++ paragraph.C 8 Aug 2002 21:00:50 -
@@ -54,7 +54,6 @@
using lyx::pos_type;
-int tex_code_break_column = 72; // needs non-zero initialization. set later.
// this is a bad idea, but how can Paragraph find its buffer to get
// parameters? (JMarc)
@@ -1188,7 +1187,7 @@
texrow.newline();
}
- if (tex_code_break_column && style->isCommand()) {
+ if (style->isCommand()) {
os << '\n';
texrow.newline();
}
Index: paragraph_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph_pimpl.C,v
retrieving revision 1.39
diff -u -r1.39 paragraph_pimpl.C
--- paragraph_pimpl.C 23 Jul 2002 21:03:37 - 1.39
+++ paragraph_pimpl.C 8 Aug 2002 21:00:52 -
@@ -31,9 +31,6 @@
using std::upper_bound;
using std::lower_bound;
-extern int tex_code_break_column;
-
-
// Initialize static member.
ShareContainer Paragraph::Pimpl::FontTable::container;
// Initialization of the counter for the paragraph id's,
@@ -249,7 +246,7 @@
LyXLayout const & style)
{
if (style.pass_thru) return;
- if (column > tex_code_break_column
+ if (column > lyxrc.ascii_linelen
&& i
&& getChar(i - 1) != ' '
&& (i < size() - 1)
@@ -263,13 +260,7 @@
|| getChar(i - 1) == '?'
|| getChar(i - 1) == ':'
|| getChar(i - 1) == '!'))) {
- if (tex_code_break_column == 0) {
- // in batchmode we need LaTeX to still
- // see it as a space not as an extra '\n'
- os << " %\n";
- } else {
- os << '\n';
- }
+ os << '\n';
texrow.newline();
texrow.start(owner_, i + 1);
column = 0;
Re: [PATCH] tex_code_break_column cruft
John Levon <[EMAIL PROTECTED]> writes: | looks like there is no need for this at all. OK ? To me? yes. -- Lgb
Buttons in BibTeX Database dialog
Hi, I think it would be better to streamline the BibTeX Database dialog with other dialogs by using the default buttons at the bottom of the dialog: [Restore] [OK] [Apply] [Close] The [Choose] button should then go. I suggest: --- Database: [___] [Browse] Style:[___] [Browse] Choose Style from list: +---+ | | [Update List] | | +---+ [Restore] [OK] [Apply] [Close] --- Regards, Rob.
INHERIT_LANGUAGE
what's the situation here ? john -- "It is unbecoming for young men to utter maxims." - Aristotle
lyx 0.10.7
OK, I am very unable to sleep and I got bored so I thought I'd get this working. What fun ... tables really sucked then, didn't they ? I see it had a feature we would really like though : a context menu on the table. Some of it almost works with current xforms, which is funny. Actually I prefer the colour scheme too Other things I much prefer about lyx 0.10.7 : root lyx-0.10.7 151 time make ... real1m5.076s user0m59.610s sys 0m3.640s root lyx-0.10.7 151 ls -l lyx -rwxrwxr-x1 root root 2836926 Aug 9 04:37 lyx root lyx-0.10.7 154 wc -l *.[Ch] | grep total 51103 total In fact, I think it's a much better starting point. Who is with me ? More seriously, it's pretty amazing to see where Lars, JMarc et al have managed to take it in 7 years ... john -- "It is unbecoming for young men to utter maxims." - Aristotle
Re: lyx 0.10.7
On Fri, 9 Aug 2002, John Levon wrote: > OK, I am very unable to sleep and I got bored so I thought I'd get > this working. > > What fun ... tables really sucked then, didn't they ? I see it had a > feature we would really like though : a context menu on the table. I must have missed that one... > Some of it almost works with current xforms, which is funny. > > Actually I prefer the colour scheme too I thought it the most hideously ugly thing I had ever seen -- just one more reason why I started using the 0.11.x development series. Much too dark and gloomy looking. > Other things I much prefer about lyx 0.10.7 : > > root lyx-0.10.7 151 time make > ... > real1m5.076s > user0m59.610s > sys 0m3.640s > > root lyx-0.10.7 151 ls -l lyx > -rwxrwxr-x1 root root 2836926 Aug 9 04:37 lyx > > root lyx-0.10.7 154 wc -l *.[Ch] | grep total > 51103 total > > In fact, I think it's a much better starting point. Who is with me ? Ah yes those were the days. Of course back then (6 years ago) the compile times were longer than you measured because the lucky ones were compiling on P-100s instead of PIII-800s (or better). Actually, I've noticed something disturbing of late: My dual overclocked Celeron-578MHz (93MHz FSB) with 128MB takes the same amount of time to compile 1.2.1cvs as the PIII-464 (103MHz FSB) with 384MB at uni (21 minutes 30 seconds). The dually used to be at least twice as fast but changes to gcc (newer versions are slower it seems) and growing complexity of code means more RAM the better. (Maybe newer kernel also has detrimental effect since PIII runs 2.2.20 and Cellies run 2.4.18) > More seriously, it's pretty amazing to see where Lars, JMarc et al have > managed to take it in 7 years ... Yeah that's for sure. And if you take out two years (nearly three) for the abandoned lyx tree it sounds even better. Allan. (ARRae)
Re: lyx 0.10.7
On Fri, Aug 09, 2002 at 02:10:18PM +1000, Allan Rae wrote: > I thought it the most hideously ugly thing I had ever seen -- just one > more reason why I started using the 0.11.x development series. Much > too dark and gloomy looking. I mean the selection colour and the greyed out below-document colour. They're lighter than they are now. > Ah yes those were the days. Of course back then (6 years ago) the > compile times were longer than you measured because the lucky ones > were compiling on P-100s instead of PIII-800s (or better). too true :) > overclocked Celeron-578MHz (93MHz FSB) with 128MB takes the same > amount of time to compile 1.2.1cvs as the PIII-464 (103MHz FSB) with > 384MB at uni (21 minutes 30 seconds). The dually used to be at least Luckily I bought half a gig during the trough in RAM prices so I never even touch swap. > > More seriously, it's pretty amazing to see where Lars, JMarc et al have > > managed to take it in 7 years ... > > Yeah that's for sure. And if you take out two years (nearly three) > for the abandoned lyx tree it sounds even better. two years ? ouch :) current lyx is worth 4 million more USD than 0.10.7 too. regards john -- "It is unbecoming for young men to utter maxims." - Aristotle
Re: nasty eqns lead to crash
On Thu, Aug 08, 2002 at 07:15:23PM +0100, John Levon wrote:
> ==9208== Conditional jump or move depends on uninitialised value(s)
> ==9208==at 0x40480B95: ostream::operator<<(int) (in
>/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so)
> ==9208==by 0x8163A63: {anonymous}::initSymbols(void) (math_factory.C:154)
> ==9208==by 0x8163B04: initMath(void) (math_factory.C:167)
> ==9208==by 0x814B07A: InsetFormulaBase::InsetFormulaBase(void)
>(formulabase.C:101)
> Andre ? Martin ?
The initMath code is correct.
> clicking on a formula :
>
> ==9208== Conditional jump or move depends on uninitialised value(s)
> ==9208==at 0x817141A: MathIterator::operator++(void) (math_iterator.C:100)
> ==9208==by 0x8155088: MathCursor::bruteFind(int, int, int, int, int, int)
>(math_cursor.C:1164)
> ==9208==by 0x815244B: MathCursor::setPos(int, int) (math_cursor.C:283)
> ==9208==by 0x814B958: InsetFormulaBase::insetButtonPress(BufferView *, int, int,
>mouse_button::state) (formulabase.C:347)
>
> Andre ?
I can't see anything wrong here, either.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: Support for LyX in design recovery tool?
On Thu, 8 Aug 2002 11:05, you wrote:
> If you get round to making a detailed step-by-step of what needs doing
> (a preliminary patch ?) I'll be glad to look further
>
Hi,
I looked into getting rid of cursor blinking for the design recovery tool.
(This makes it easier to track the cursor from screenshots.) Apparently,
it's not easy to do since every inset has its own cursor blinking code, some
of which is not trivial (e.g., tabular inset).
I tried making the following change in BufferView_pimpl.C at the end of
of the void BufferView::Pimpl::cursorToggle() method:
// change toggle calls to show calls
if (!bv_->theLockingInset()) {
bv_->showCursor(); // instead of toggle
} else {
bv_->theLockingInset()->showInsetCursor(bv_); // instead of toggle
}
cursor_timeout.restart(); // as before
}
This works for the normal cursor and most but not all inset cursors. In
particular, it doesn't work for the tabular inset. Apparently, some
non-trivial work is being done in its toggle method.
BTW, getting rid of the cursor timeout doesn't work since in some cases the
cursor is not shown at all unless it is toggled from a timeout.
Also, I tried changing the cursor color using the dialog in the GUI. (Again,
a unique cursor color makes it easier to track the cursor from screenshots.)
For some reason, the cursor color changes were always ignored (lyx 1.2).
The color sliders also had some problems. For example, I couldn't pick
254 for red; it only gave me 253 or 255. Perhaps there is a way to explicitly
specify RGB values from the startup file?
Amir
> regards
> john
> --
> "It is unbecoming for young men to utter maxims."
> - Aristotle
>
>
Re: lyx 0.10.7
On Fri, Aug 09, 2002 at 04:46:47AM +0100, John Levon wrote: > Other things I much prefer about lyx 0.10.7 : > > root lyx-0.10.7 151 time make > ... > real1m5.076s > user0m59.610s > sys 0m3.640s > > root lyx-0.10.7 151 ls -l lyx > -rwxrwxr-x1 root root 2836926 Aug 9 04:37 lyx > > root lyx-0.10.7 154 wc -l *.[Ch] | grep total > 51103 total Waah... open wounds... > More seriously, it's pretty amazing to see where Lars, JMarc et al have > managed to take it in 7 years ... 'Amazing' is an interesting word ;-} Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
