[another patch] Re: Feature Request: toolbar for phonetic symbols (IPA)
Jürgen Spitzmüller wrote:
\textipa{\textepsilon{}kspl\textschwa{}ne\textsci{}\textesh{}\textschwa{}n}
which is not only hardly readable (due to the macros), but also the kerning
is broken by the {} which are appended after each macro.
The kerning problem is addressed by the attached patch (which is on top of the
other, as you can see). It assures the '{}' are only appended when needed (if
a space follows). If a normal character follows, a blank is appended, if a
macro follows, nothing is appended. So you get:
\textipa{\textepsilon kspl\textschwa ne\textsci\textesh\textschwa n}
which is the correct output.
JürgenIndex: src/Paragraph.cpp
===
--- src/Paragraph.cpp (Revision 40866)
+++ src/Paragraph.cpp (Arbeitskopie)
@@ -1253,8 +1253,9 @@
return;
Encoding const encoding = *(runparams.encoding);
+ char_type next = '\0';
if (i + 1 int(text_.size())) {
- char_type next = text_[i + 1];
+ next = text_[i + 1];
if (Encodings::isCombiningChar(next)) {
column += latexSurrogatePair(os, c, next, runparams) - 1;
++i;
@@ -1262,18 +1263,31 @@
}
}
string script;
- docstring const latex = encoding.latexChar(c);
+ docstring latex = encoding.latexChar(c);
+ docstring nextlatex = (next == '\0') ? docstring(): encoding.latexChar(next);
+ bool tipas = false;
+ if (runparams.inIPA) {
+ string const tipashortcut = Encodings::TIPAShortcut(c);
+ if (!tipashortcut.empty()) {
+latex = from_ascii(tipashortcut);
+tipas = true;
+ }
+ }
if (Encodings::isKnownScriptChar(c, script)
prefixIs(latex, from_ascii(\\ + script)))
column += writeScriptChars(os, latex,
running_change, encoding, i) - 1;
- else if (latex.length() 1 latex[latex.length() - 1] != '}'
- latex[latex.length() - 1] != '-') {
+ else if (!prefixIs(nextlatex, from_ascii(\\))
+ latex.length() 1 latex[latex.length() - 1] != '}'
+ latex[latex.length() - 1] != '-' !tipas) {
// Prevent eating of a following
// space or command corruption by
// following characters
column += latex.length() + 1;
- os latex {};
+ if (next == ' ' || next == '\0')
+os latex {};
+ else
+os latex ;
} else {
column += latex.length() - 1;
os latex;
[another patch] Re: Feature Request: toolbar for phonetic symbols (IPA)
Jürgen Spitzmüller wrote:
> \textipa{\textepsilon{}kspl\textschwa{}ne\textsci{}\textesh{}\textschwa{}n}
>
> which is not only hardly readable (due to the macros), but also the kerning
> is broken by the {} which are appended after each macro.
The kerning problem is addressed by the attached patch (which is on top of the
other, as you can see). It assures the '{}' are only appended when needed (if
a space follows). If a normal character follows, a blank is appended, if a
macro follows, nothing is appended. So you get:
\textipa{\textepsilon kspl\textschwa ne\textsci\textesh\textschwa n}
which is the correct output.
JürgenIndex: src/Paragraph.cpp
===
--- src/Paragraph.cpp (Revision 40866)
+++ src/Paragraph.cpp (Arbeitskopie)
@@ -1253,8 +1253,9 @@
return;
Encoding const & encoding = *(runparams.encoding);
+ char_type next = '\0';
if (i + 1 < int(text_.size())) {
- char_type next = text_[i + 1];
+ next = text_[i + 1];
if (Encodings::isCombiningChar(next)) {
column += latexSurrogatePair(os, c, next, runparams) - 1;
++i;
@@ -1262,18 +1263,31 @@
}
}
string script;
- docstring const latex = encoding.latexChar(c);
+ docstring latex = encoding.latexChar(c);
+ docstring nextlatex = (next == '\0') ? docstring(): encoding.latexChar(next);
+ bool tipas = false;
+ if (runparams.inIPA) {
+ string const tipashortcut = Encodings::TIPAShortcut(c);
+ if (!tipashortcut.empty()) {
+latex = from_ascii(tipashortcut);
+tipas = true;
+ }
+ }
if (Encodings::isKnownScriptChar(c, script)
&& prefixIs(latex, from_ascii("\\" + script)))
column += writeScriptChars(os, latex,
running_change, encoding, i) - 1;
- else if (latex.length() > 1 && latex[latex.length() - 1] != '}' &&
- latex[latex.length() - 1] != '-') {
+ else if (!prefixIs(nextlatex, from_ascii("\\"))
+ && latex.length() > 1 && latex[latex.length() - 1] != '}'
+ && latex[latex.length() - 1] != '-' && !tipas) {
// Prevent eating of a following
// space or command corruption by
// following characters
column += latex.length() + 1;
- os << latex << "{}";
+ if (next == ' ' || next == '\0')
+os << latex << "{}";
+ else
+os << latex << " ";
} else {
column += latex.length() - 1;
os << latex;
Re: Another patch for 1.6.x
Stephan Witt wrote: I have another patch in my local branch checkout... It fixes a warning and a potential bug. OK. Jürgen
Re: Another patch for 1.6.x
Stephan Witt wrote: > I have another patch in my local branch checkout... > It fixes a warning and a potential bug. OK. Jürgen
Another patch for 1.6.x
I have another patch in my local branch checkout... It fixes a warning and a potential bug. Stephan Index: src/mathed/InsetMathHull.cpp === --- src/mathed/InsetMathHull.cpp(Revision 35627) +++ src/mathed/InsetMathHull.cpp(Arbeitskopie) @@ -1403,7 +1403,7 @@ case LFUN_MATH_NUMBER_TOGGLE: // FIXME: what is the right test, this or the one of // LABEL_INSERT? - status.setEnabled(display()); + status.setEnabled(display() != Inline); status.setOnOff(numberedType()); return true;
Another patch for 1.6.x
I have another patch in my local branch checkout... It fixes a warning and a potential bug. Stephan Index: src/mathed/InsetMathHull.cpp === --- src/mathed/InsetMathHull.cpp(Revision 35627) +++ src/mathed/InsetMathHull.cpp(Arbeitskopie) @@ -1403,7 +1403,7 @@ case LFUN_MATH_NUMBER_TOGGLE: // FIXME: what is the right test, this or the one of // LABEL_INSERT? - status.setEnabled(display()); + status.setEnabled(display() != Inline); status.setOnOff(numberedType()); return true;
Re: [yet another patch] Cursor movement fine-tuning
So, removing the whole boundary business, we get this behavious: 1) abc| \ndef =right= abc \n|def 2) ab|c\ndef =right= abc\n|def =right= abc\nd|ef 3) abc \nd|ef =left= abc \n|def =left= abc| \ndef 4) abc\nd|ef =left= abc\ndef =left= ab|c\ndef 5) abc|newline\ndef =right= abcnewline\n|def 6) abcnewlined|ef =left= abcnewline|def =left= abc|newlinedef 7) ab|c\n$$1$$\ndef =right= abc\n|$$1$$\ndef =right= abc\n$$|1$$\ndef 8) abc\n$$|1$$\ndef =right= abc\n$$1|$$\ndef =right= abc\n$$1$$|\ndef 9) abc\n$$1$$|\ndef =right= abc\n$$1$$\n|def This is fine, mostly. I don't like 7. There should be a position behind the c, because if you type with the cursor in front of the $$1$ $ the characters appear behind c. In fact the position in front of $$1 $$ shouldn't exist because typing there makes no sense. The same is true for the position behind $$1$$ (see 8). All these cases apply to cursor left/right. If you use the mouse or cursor up/down, what should happen? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [yet another patch] Cursor movement fine-tuning
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan This is fine, mostly. I don't like 7. There should be a Stefan position behind the c, because if you type with the cursor in Stefan front of the $$1$ $ the characters appear behind c. In fact Stefan the position in front of $$1 $$ shouldn't exist because typing Stefan there makes no sense. The same is true for the position behind Stefan $$1$$ (see 8). A whole part of this boundary code has been implemented to catter with this particular case. JMarc
Re: [yet another patch] Cursor movement fine-tuning
Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan This is fine, mostly. I don't like 7. There should be a Stefan position behind the c, because if you type with the cursor in Stefan front of the $$1$ $ the characters appear behind c. In fact Stefan the position in front of $$1 $$ shouldn't exist because typing Stefan there makes no sense. The same is true for the position behind Stefan $$1$$ (see 8). A whole part of this boundary code has been implemented to catter with this particular case. What do you mean? Those positions are supposed to exist or not? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [yet another patch] Cursor movement fine-tuning
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan This is fine, mostly. I don't like 7. There should be a Stefan position behind the c, because if you type with the cursor in Stefan front of the $$1$ $ the characters appear behind c. In fact Stefan the position in front of $$1 $$ shouldn't exist because typing Stefan there makes no sense. The same is true for the position behind Stefan $$1$$ (see 8). A whole part of this boundary code has been implemented to catter with this particular case. Stefan What do you mean? Those positions are supposed to exist or Stefan not? Good question. In 1.4.x, the two positions exist. I am not sure why the position in front of the display inset is deemed useful. JMarc
Re: [yet another patch] Cursor movement fine-tuning
Am 31.05.2007 um 09:57 schrieb Jean-Marc Lasgouttes: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan This is fine, mostly. I don't like 7. There should be a Stefan position behind the c, because if you type with the cursor in Stefan front of the $$1$ $ the characters appear behind c. In fact Stefan the position in front of $$1 $$ shouldn't exist because typing Stefan there makes no sense. The same is true for the position behind Stefan $$1$$ (see 8). A whole part of this boundary code has been implemented to catter with this particular case. Stefan What do you mean? Those positions are supposed to exist or Stefan not? Good question. In 1.4.x, the two positions exist. I am not sure why the position in front of the display inset is deemed useful. The only case I can imagine is while selecting an inset like display math. It might seem more intuitive if you can select just the line of a display math. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [yet another patch] Cursor movement fine-tuning
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan The only case I can imagine is while selecting an inset like Stefan display math. It might seem more intuitive if you can select Stefan just the line of a display math. But the visual effect will remain the same anyway. I have the feeling that there was a reason, but I cannot remember which one. JMarc
Re: [yet another patch] Cursor movement fine-tuning
Am 31.05.2007 um 10:13 schrieb Jean-Marc Lasgouttes: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan The only case I can imagine is while selecting an inset like Stefan display math. It might seem more intuitive if you can select Stefan just the line of a display math. But the visual effect will remain the same anyway. Nearly. The margin is overdrawn with the selection color as well if the in-front-of-display-math position does not exist. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [yet another patch] Cursor movement fine-tuning
Jean-Marc Lasgouttes wrote: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan This is fine, mostly. I don't like 7. There should be a Stefan position behind the c, because if you type with the cursor in Stefan front of the $$1$ $ the characters appear behind c. In fact Stefan the position in front of $$1 $$ shouldn't exist because typing Stefan there makes no sense. The same is true for the position behind Stefan $$1$$ (see 8). A whole part of this boundary code has been implemented to catter with this particular case. Stefan What do you mean? Those positions are supposed to exist or Stefan not? Good question. In 1.4.x, the two positions exist. I am not sure why the position in front of the display inset is deemed useful. Isn't this related to change-tracking? Abdel.
Re: [yet another patch] Cursor movement fine-tuning
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Good question. In 1.4.x, the two positions exist. I am not sure why the position in front of the display inset is deemed useful. Abdelrazak Isn't this related to change-tracking? I think it is something else, but what? JMarc
Re: [yet another patch] Cursor movement fine-tuning
Abdelrazak Younes schrieb: Isn't this related to change-tracking? Change tracking adds meta information to a virtual (i.e. non-existing) end-of-par character at the end of each paragraph. It does not care for cursor stuff. (I haven't follow the thread but I hope that you did not kill any CT-related code. (The cursor movement code should be completely CT-free)) Michael
Re: [yet another patch] Cursor movement fine-tuning
Michael Gerz wrote: Abdelrazak Younes schrieb: Isn't this related to change-tracking? Change tracking adds meta information to a virtual (i.e. non-existing) end-of-par character at the end of each paragraph. Ah yes I remembered something about a virtual end-of-par. It does not care for cursor stuff. OK, thanks for the explanation. Abdel.
Re: [yet another patch] Cursor movement fine-tuning
Am 31.05.2007 um 10:56 schrieb Michael Gerz: Abdelrazak Younes schrieb: Isn't this related to change-tracking? Change tracking adds meta information to a virtual (i.e. non- existing) end-of-par character at the end of each paragraph. It does not care for cursor stuff. (I haven't follow the thread but I hope that you did not kill any CT-related code. (The cursor movement code should be completely CT- free)) How does this meta information look like? Is it a character? Where is it exactly? After endpos() ? Must it be skipped somehwere? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [yet another patch] Cursor movement fine-tuning
Stefan Schimanski schrieb: Am 31.05.2007 um 10:56 schrieb Michael Gerz: Abdelrazak Younes schrieb: Isn't this related to change-tracking? Change tracking adds meta information to a virtual (i.e. non-existing) end-of-par character at the end of each paragraph. It does not care for cursor stuff. (I haven't follow the thread but I hope that you did not kill any CT-related code. (The cursor movement code should be completely CT-free)) How does this meta information look like? Is it a character? Where is it exactly? After endpos() ? Must it be skipped somehwere? The Paragraph class has an internal CT structure that is updated whenever we insert or delete a character. For end-of-par, the structure also covers position par.size() which does not exist. Example in readParagraph(...): // Final change goes to paragraph break: par.setChange(par.size(), change); HTH, Michael
Re: [yet another patch] Cursor movement fine-tuning
On Thu, May 31, 2007 at 09:25:15AM +0200, Stefan Schimanski wrote: So, removing the whole boundary business, we get this behavious: 1) abc| \ndef =right= abc \n|def 2) ab|c\ndef =right= abc\n|def =right= abc\nd|ef 3) abc \nd|ef =left= abc \n|def =left= abc| \ndef 4) abc\nd|ef =left= abc\ndef =left= ab|c\ndef 5) abc|newline\ndef =right= abcnewline\n|def 6) abcnewlined|ef =left= abcnewline|def =left= abc|newlinedef 7) ab|c\n$$1$$\ndef =right= abc\n|$$1$$\ndef =right= abc\n$$|1$$\ndef 8) abc\n$$|1$$\ndef =right= abc\n$$1|$$\ndef =right= abc\n$$1$$|\ndef 9) abc\n$$1$$|\ndef =right= abc\n$$1$$\n|def This is fine, mostly. I don't like 7. There should be a position behind the c, because if you type with the cursor in front of the $$1$ $ the characters appear behind c. In fact the position in front of $$1 $$ shouldn't exist because typing there makes no sense. The same is true for the position behind $$1$$ (see 8). All these cases apply to cursor left/right. If you use the mouse or cursor up/down, what should happen? If you click near the end of a line, the cursor should be positioned there. If you click near the beginning, it goes there. Going up/down from the beginning of a line should keep the cursor neear the beginning of the line above/below. Same for the end. Andre'
Re: [yet another patch] Cursor movement fine-tuning
On Thu, May 31, 2007 at 09:50:03AM +0200, Stefan Schimanski wrote: Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan This is fine, mostly. I don't like 7. There should be a Stefan position behind the c, because if you type with the cursor in Stefan front of the $$1$ $ the characters appear behind c. In fact Stefan the position in front of $$1 $$ shouldn't exist because typing Stefan there makes no sense. The same is true for the position behind Stefan $$1$$ (see 8). A whole part of this boundary code has been implemented to catter with this particular case. What do you mean? Those positions are supposed to exist or not? They do not exist in the buffer structure, but they exist on screen. That's the very reason for the existance of the boundary flag. Andre'
Re: [yet another patch] Cursor movement fine-tuning
Stefan Schimanski schrieb: Am 31.05.2007 um 10:56 schrieb Michael Gerz: Abdelrazak Younes schrieb: Isn't this related to change-tracking? Change tracking adds meta information to a virtual (i.e. non-existing) end-of-par character at the end of each paragraph. It does not care for cursor stuff. (I haven't follow the thread but I hope that you did not kill any CT-related code. (The cursor movement code should be completely CT-free)) How does this meta information look like? Is it a character? Where is it exactly? After endpos() ? Must it be skipped somehwere? The Paragraph class has an internal CT structure that is updated whenever we insert or delete a character. For end-of-par, the structure also covers position "par.size()" which does not exist. Example in readParagraph(...): // Final change goes to paragraph break: par.setChange(par.size(), change); HTH, Michael
Re: [yet another patch] Cursor movement fine-tuning
On Thu, May 31, 2007 at 09:25:15AM +0200, Stefan Schimanski wrote: > So, removing the whole boundary business, we get this behavious: > > 1) abc| \ndef =right=> abc \n|def > 2) ab|c\ndef =right=> abc\n|def =right=> abc\nd|ef > 3) abc \nd|ef =left=> abc \n|def =left=> abc| \ndef > 4) abc\nd|ef =left=> abc\ndef =left=> ab|c\ndef > 5) abc|\ndef =right=> abc\n|def > 6) abcd|ef =left=> abc|def =left=> abc|def > 7) ab|c\n$$1$$\ndef =right=> abc\n|$$1$$\ndef =right=> abc\n$$|1$$\ndef > 8) abc\n$$|1$$\ndef =right=> abc\n$$1|$$\ndef =right=> abc\n$$1$$|\ndef > 9) abc\n$$1$$|\ndef =right=> abc\n$$1$$\n|def > > This is fine, mostly. I don't like 7. There should be a position > behind the c, because if you type with the cursor in front of the $$1$ > $ the characters appear behind c. In fact the position in front of $$1 > $$ shouldn't exist because typing there makes no sense. The same is > true for the position behind $$1$$ (see 8). > > All these cases apply to cursor left/right. If you use the mouse or > cursor up/down, what should happen? If you click near the end of a line, the cursor should be positioned there. If you click near the beginning, it goes there. Going up/down from the beginning of a line should keep the cursor neear the beginning of the line above/below. Same for the end. Andre'
Re: [yet another patch] Cursor movement fine-tuning
On Thu, May 31, 2007 at 09:50:03AM +0200, Stefan Schimanski wrote: > > Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes: > > >>"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: > > > >Stefan> This is fine, mostly. I don't like 7. There should be a > >Stefan> position behind the c, because if you type with the cursor in > >Stefan> front of the $$1$ $ the characters appear behind c. In fact > >Stefan> the position in front of $$1 $$ shouldn't exist because typing > >Stefan> there makes no sense. The same is true for the position behind > >Stefan> $$1$$ (see 8). > > > >A whole part of this boundary code has been implemented to catter with > >this particular case. > > What do you mean? Those positions are supposed to exist or not? They do not exist in the buffer structure, but they exist on screen. That's the very reason for the existance of the boundary flag. Andre'
Re: [yet another patch] Cursor movement fine-tuning
So, removing the whole boundary business, we get this behavious: 1) abc| \ndef =right=> abc \n|def 2) ab|c\ndef =right=> abc\n|def =right=> abc\nd|ef 3) abc \nd|ef =left=> abc \n|def =left=> abc| \ndef 4) abc\nd|ef =left=> abc\ndef =left=> ab|c\ndef 5) abc|\ndef =right=> abc\n|def 6) abcd|ef =left=> abc|def =left=> abc|def 7) ab|c\n$$1$$\ndef =right=> abc\n|$$1$$\ndef =right=> abc\n$$|1$$\ndef 8) abc\n$$|1$$\ndef =right=> abc\n$$1|$$\ndef =right=> abc\n$$1$$|\ndef 9) abc\n$$1$$|\ndef =right=> abc\n$$1$$\n|def This is fine, mostly. I don't like 7. There should be a position behind the c, because if you type with the cursor in front of the $$1$ $ the characters appear behind c. In fact the position in front of $$1 $$ shouldn't exist because typing there makes no sense. The same is true for the position behind $$1$$ (see 8). All these cases apply to cursor left/right. If you use the mouse or cursor up/down, what should happen? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [yet another patch] Cursor movement fine-tuning
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> This is fine, mostly. I don't like 7. There should be a Stefan> position behind the c, because if you type with the cursor in Stefan> front of the $$1$ $ the characters appear behind c. In fact Stefan> the position in front of $$1 $$ shouldn't exist because typing Stefan> there makes no sense. The same is true for the position behind Stefan> $$1$$ (see 8). A whole part of this boundary code has been implemented to catter with this particular case. JMarc
Re: [yet another patch] Cursor movement fine-tuning
Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes: "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> This is fine, mostly. I don't like 7. There should be a Stefan> position behind the c, because if you type with the cursor in Stefan> front of the $$1$ $ the characters appear behind c. In fact Stefan> the position in front of $$1 $$ shouldn't exist because typing Stefan> there makes no sense. The same is true for the position behind Stefan> $$1$$ (see 8). A whole part of this boundary code has been implemented to catter with this particular case. What do you mean? Those positions are supposed to exist or not? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [yet another patch] Cursor movement fine-tuning
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes: >>> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: >> Stefan> This is fine, mostly. I don't like 7. There should be a Stefan> position behind the c, because if you type with the cursor in Stefan> front of the $$1$ $ the characters appear behind c. In fact Stefan> the position in front of $$1 $$ shouldn't exist because typing Stefan> there makes no sense. The same is true for the position behind Stefan> $$1$$ (see 8). >> A whole part of this boundary code has been implemented to catter >> with this particular case. Stefan> What do you mean? Those positions are supposed to exist or Stefan> not? Good question. In 1.4.x, the two positions exist. I am not sure why the position in front of the display inset is deemed useful. JMarc
Re: [yet another patch] Cursor movement fine-tuning
Am 31.05.2007 um 09:57 schrieb Jean-Marc Lasgouttes: "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes: "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> This is fine, mostly. I don't like 7. There should be a Stefan> position behind the c, because if you type with the cursor in Stefan> front of the $$1$ $ the characters appear behind c. In fact Stefan> the position in front of $$1 $$ shouldn't exist because typing Stefan> there makes no sense. The same is true for the position behind Stefan> $$1$$ (see 8). A whole part of this boundary code has been implemented to catter with this particular case. Stefan> What do you mean? Those positions are supposed to exist or Stefan> not? Good question. In 1.4.x, the two positions exist. I am not sure why the position in front of the display inset is deemed useful. The only case I can imagine is while selecting an inset like display math. It might seem more intuitive if you can select just the line of a display math. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [yet another patch] Cursor movement fine-tuning
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> The only case I can imagine is while selecting an inset like Stefan> display math. It might seem more intuitive if you can select Stefan> just the line of a display math. But the visual effect will remain the same anyway. I have the feeling that there was a reason, but I cannot remember which one. JMarc
Re: [yet another patch] Cursor movement fine-tuning
Am 31.05.2007 um 10:13 schrieb Jean-Marc Lasgouttes: "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> The only case I can imagine is while selecting an inset like Stefan> display math. It might seem more intuitive if you can select Stefan> just the line of a display math. But the visual effect will remain the same anyway. Nearly. The margin is overdrawn with the selection color as well if the in-front-of-display-math position does not exist. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [yet another patch] Cursor movement fine-tuning
Jean-Marc Lasgouttes wrote: "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes: "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> This is fine, mostly. I don't like 7. There should be a Stefan> position behind the c, because if you type with the cursor in Stefan> front of the $$1$ $ the characters appear behind c. In fact Stefan> the position in front of $$1 $$ shouldn't exist because typing Stefan> there makes no sense. The same is true for the position behind Stefan> $$1$$ (see 8). A whole part of this boundary code has been implemented to catter with this particular case. Stefan> What do you mean? Those positions are supposed to exist or Stefan> not? Good question. In 1.4.x, the two positions exist. I am not sure why the position in front of the display inset is deemed useful. Isn't this related to change-tracking? Abdel.
Re: [yet another patch] Cursor movement fine-tuning
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> Good question. In 1.4.x, the two positions exist. I am not sure >> why the position in front of the display inset is deemed useful. Abdelrazak> Isn't this related to change-tracking? I think it is something else, but what? JMarc
Re: [yet another patch] Cursor movement fine-tuning
Abdelrazak Younes schrieb: Isn't this related to change-tracking? Change tracking adds meta information to a virtual (i.e. non-existing) end-of-par character at the end of each paragraph. It does not care for cursor stuff. (I haven't follow the thread but I hope that you did not kill any CT-related code. (The cursor movement code should be completely CT-free)) Michael
Re: [yet another patch] Cursor movement fine-tuning
Michael Gerz wrote: Abdelrazak Younes schrieb: Isn't this related to change-tracking? Change tracking adds meta information to a virtual (i.e. non-existing) end-of-par character at the end of each paragraph. Ah yes I remembered something about a virtual end-of-par. It does not care for cursor stuff. OK, thanks for the explanation. Abdel.
Re: [yet another patch] Cursor movement fine-tuning
Am 31.05.2007 um 10:56 schrieb Michael Gerz: Abdelrazak Younes schrieb: Isn't this related to change-tracking? Change tracking adds meta information to a virtual (i.e. non- existing) end-of-par character at the end of each paragraph. It does not care for cursor stuff. (I haven't follow the thread but I hope that you did not kill any CT-related code. (The cursor movement code should be completely CT- free)) How does this meta information look like? Is it a character? Where is it exactly? After endpos() ? Must it be skipped somehwere? Stefan PGP.sig Description: Signierter Teil der Nachricht
[yet another patch] Cursor movement fine-tuning
[This should be applied after the patch in
http://permalink.gmane.org/gmane.editors.lyx.devel/86074, which fixes
bug 3754.]
Okay, you guys (Stefan and Andre') are correct, as always ;) .
We really don't need the boundary almost anywhere. The comment on
boundary_ in DocIterator.h is (almost) right: the only place we're using
it at the moment is for Bidi. It should still be corrected in terms of
(i,i+1)-(i-1,i), and also I think an overview of how it's used in
cursor drawing is important for understanding how it's to be used, so
that should stay there (if you want, tomorrow night I'll send in a
suggestion for patching the comment).
At least cursorLeft and cursorRight are much simpler now... I wonder if
this'll speed them up a little, too...
One thing that's still bugging is why Left and Right aren't symmetrical.
For some reason we still need the condition for Bidi in right, but not
in left. I suspect maybe it has to do with the choice of boundary being
between (i-1,i), which is in a sense a symmetry break?
Anyhow, please test this against all the cursor-related fixes from the
past few days, but I think this'll work, and it's much simpler (and it
gets rid of the debug variables, too...)
Good night!
Dov
Index: lyx-devel/src/Text2.cpp
===
--- lyx-devel.orig/src/Text2.cpp2007-05-31 02:14:58.0 +0300
+++ lyx-devel/src/Text2.cpp 2007-05-31 02:17:39.0 +0300
@@ -988,26 +988,6 @@
// not at paragraph start?
if (cur.pos() 0) {
- // if on right side of boundary (i.e. not at paragraph end, but
line end)
- // - skip it, i.e. set boundary to true, i.e. go only
logically left
- // there are some exceptions to ignore this: lineseps,
newlines, spaces
-#if 0
- // some effectless debug code to see the values in the debugger
- bool bound = cur.boundary();
- int rowpos = cur.textRow().pos();
- int pos = cur.pos();
- bool sep = cur.paragraph().isSeparator(cur.pos() - 1);
- bool newline = cur.paragraph().isNewline(cur.pos() - 1);
- bool linesep = cur.paragraph().isLineSeparator(cur.pos() - 1);
-#endif
- if (!cur.boundary()
- cur.textRow().pos() == cur.pos()
- !cur.paragraph().isLineSeparator(cur.pos() - 1)
- !cur.paragraph().isNewline(cur.pos() - 1)
- !cur.paragraph().isSeparator(cur.pos() - 1)) {
- return setCursor(cur, cur.pit(), cur.pos(), true, true);
- }
-
// go left and try to enter inset
if (checkAndActivateInset(cur, false))
return false;
@@ -1041,30 +1021,6 @@
if (checkAndActivateInset(cur, true))
return false;
- // next position is left of boundary,
- // but go to next line for special cases like space, newline,
linesep
-#if 0
- // some effectless debug code to see the values in the debugger
- int endpos = cur.textRow().endpos();
- int lastpos = cur.lastpos();
- int pos = cur.pos();
- bool linesep = cur.paragraph().isLineSeparator(cur.pos());
- bool newline = cur.paragraph().isNewline(cur.pos());
- bool sep = cur.paragraph().isSeparator(cur.pos());
- if (cur.pos() != cur.lastpos()) {
- bool linesep2 =
cur.paragraph().isLineSeparator(cur.pos()+1);
- bool newline2 = cur.paragraph().isNewline(cur.pos()+1);
- bool sep2 = cur.paragraph().isSeparator(cur.pos()+1);
- }
-#endif
- if (cur.textRow().endpos() == cur.pos() + 1
- cur.textRow().endpos() != cur.lastpos()
- !cur.paragraph().isNewline(cur.pos())
- !cur.paragraph().isLineSeparator(cur.pos())
- !cur.paragraph().isSeparator(cur.pos())) {
- return setCursor(cur, cur.pit(), cur.pos() + 1, true,
true);
- }
-
// in front of RTL boundary? Stay on this side of the boundary
because:
// ab|cDDEEFFghi - abc|DDEEFFghi
if (bidi.isBoundary(cur.buffer(), cur.paragraph(), cur.pos() +
1)) {
Re: [yet another patch] Cursor movement fine-tuning
On Thu, May 31, 2007 at 02:29:38AM +0300, Dov Feldstern wrote: At least cursorLeft and cursorRight are much simpler now... I have no idea whether the patch is sound, but I certainly like the structure... Andre'
[yet another patch] Cursor movement fine-tuning
[This should be applied after the patch in
http://permalink.gmane.org/gmane.editors.lyx.devel/86074, which fixes
bug 3754.]
Okay, you guys (Stefan and Andre') are correct, as always ;) .
We really don't need the boundary almost anywhere. The comment on
boundary_ in DocIterator.h is (almost) right: the only place we're using
it at the moment is for Bidi. It should still be corrected in terms of
(i,i+1)->(i-1,i), and also I think an overview of how it's used in
cursor drawing is important for understanding how it's to be used, so
that should stay there (if you want, tomorrow night I'll send in a
suggestion for patching the comment).
At least cursorLeft and cursorRight are much simpler now... I wonder if
this'll speed them up a little, too...
One thing that's still bugging is why Left and Right aren't symmetrical.
For some reason we still need the condition for Bidi in right, but not
in left. I suspect maybe it has to do with the choice of boundary being
between (i-1,i), which is in a sense a symmetry break?
Anyhow, please test this against all the cursor-related fixes from the
past few days, but I think this'll work, and it's much simpler (and it
gets rid of the debug variables, too...)
Good night!
Dov
Index: lyx-devel/src/Text2.cpp
===
--- lyx-devel.orig/src/Text2.cpp2007-05-31 02:14:58.0 +0300
+++ lyx-devel/src/Text2.cpp 2007-05-31 02:17:39.0 +0300
@@ -988,26 +988,6 @@
// not at paragraph start?
if (cur.pos() > 0) {
- // if on right side of boundary (i.e. not at paragraph end, but
line end)
- // -> skip it, i.e. set boundary to true, i.e. go only
logically left
- // there are some exceptions to ignore this: lineseps,
newlines, spaces
-#if 0
- // some effectless debug code to see the values in the debugger
- bool bound = cur.boundary();
- int rowpos = cur.textRow().pos();
- int pos = cur.pos();
- bool sep = cur.paragraph().isSeparator(cur.pos() - 1);
- bool newline = cur.paragraph().isNewline(cur.pos() - 1);
- bool linesep = cur.paragraph().isLineSeparator(cur.pos() - 1);
-#endif
- if (!cur.boundary() &&
- cur.textRow().pos() == cur.pos() &&
- !cur.paragraph().isLineSeparator(cur.pos() - 1)
&&
- !cur.paragraph().isNewline(cur.pos() - 1) &&
- !cur.paragraph().isSeparator(cur.pos() - 1)) {
- return setCursor(cur, cur.pit(), cur.pos(), true, true);
- }
-
// go left and try to enter inset
if (checkAndActivateInset(cur, false))
return false;
@@ -1041,30 +1021,6 @@
if (checkAndActivateInset(cur, true))
return false;
- // next position is left of boundary,
- // but go to next line for special cases like space, newline,
linesep
-#if 0
- // some effectless debug code to see the values in the debugger
- int endpos = cur.textRow().endpos();
- int lastpos = cur.lastpos();
- int pos = cur.pos();
- bool linesep = cur.paragraph().isLineSeparator(cur.pos());
- bool newline = cur.paragraph().isNewline(cur.pos());
- bool sep = cur.paragraph().isSeparator(cur.pos());
- if (cur.pos() != cur.lastpos()) {
- bool linesep2 =
cur.paragraph().isLineSeparator(cur.pos()+1);
- bool newline2 = cur.paragraph().isNewline(cur.pos()+1);
- bool sep2 = cur.paragraph().isSeparator(cur.pos()+1);
- }
-#endif
- if (cur.textRow().endpos() == cur.pos() + 1 &&
- cur.textRow().endpos() != cur.lastpos() &&
- !cur.paragraph().isNewline(cur.pos()) &&
- !cur.paragraph().isLineSeparator(cur.pos()) &&
- !cur.paragraph().isSeparator(cur.pos())) {
- return setCursor(cur, cur.pit(), cur.pos() + 1, true,
true);
- }
-
// in front of RTL boundary? Stay on this side of the boundary
because:
// ab|cDDEEFFghi -> abc|DDEEFFghi
if (bidi.isBoundary(cur.buffer(), cur.paragraph(), cur.pos() +
1)) {
Re: [yet another patch] Cursor movement fine-tuning
On Thu, May 31, 2007 at 02:29:38AM +0300, Dov Feldstern wrote: > At least cursorLeft and cursorRight are much simpler now... I have no idea whether the patch is sound, but I certainly like the structure... Andre'
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
John McCabe-Dansted wrote: John If LyX locked files which were open in a still running LyX John process, that would have saved me some confusion. Yes, but I am sure this can cause a lot of confusion too... I am not sure why this would cause confusion. You could have a dialog box warning that Another LyX window has this file open and offer some of the following alternatives: * Do not open. fine * Open read only. fine * Open anyway. fine, assume the user sorts it out after being warned * Attempt to kill other LyX window. How? Killing the process is no good, that process may have several unsaved documents open. And it might belong to another user anyway. Helge Hafting
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc Anyway, I have an additional patch for this bug. Anyone Jean-Marc disagrees? Applied. JMarc
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
Helge Hafting [EMAIL PROTECTED] writes: | John McCabe-Dansted wrote: | | John If LyX locked files which were open in a still running LyX | John process, that would have saved me some confusion. | | Yes, but I am sure this can cause a lot of confusion too... | | | I am not sure why this would cause confusion. You could have a dialog | box warning that Another LyX window has this file open and offer | some of the following alternatives: | | * Do not open. | | fine | | * Open read only. | | fine | | * Open anyway. | | fine, assume the user sorts it out after being warned Please have a look at how emacs does this. (I am in favor of the 'when in doubt do as emacs' camp.) -- Lgb
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Please have a look at how emacs does this. (I am in favor of the Lars 'when in doubt do as emacs' camp.) It uses a ~/.emacs-places file which contains a list of files and offsets. JMarc
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
John McCabe-Dansted wrote: John> If LyX locked files which were open in a still running LyX John> process, that would have saved me some confusion. Yes, but I am sure this can cause a lot of confusion too... I am not sure why this would cause confusion. You could have a dialog box warning that "Another LyX window has this file open" and offer some of the following alternatives: * Do not open. fine * Open read only. fine * Open anyway. fine, assume the user sorts it out after being warned * Attempt to kill other LyX window. How? Killing the process is no good, that process may have several unsaved documents open. And it might belong to another user anyway. Helge Hafting
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> Anyway, I have an additional patch for this bug. Anyone Jean-Marc> disagrees? Applied. JMarc
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
Helge Hafting <[EMAIL PROTECTED]> writes: | John McCabe-Dansted wrote: | | >>John> If LyX locked files which were open in a still running LyX | >>John> process, that would have saved me some confusion. | >> | >>Yes, but I am sure this can cause a lot of confusion too... | >> | > | >I am not sure why this would cause confusion. You could have a dialog | >box warning that "Another LyX window has this file open" and offer | >some of the following alternatives: | > | >* Do not open. | > | fine | | >* Open read only. | > | fine | | >* Open anyway. | > | fine, assume the user sorts it out after being warned Please have a look at how emacs does this. (I am in favor of the 'when in doubt do as emacs' camp.) -- Lgb
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Please have a look at how emacs does this. (I am in favor of the Lars> 'when in doubt do as emacs' camp.) It uses a ~/.emacs-places file which contains a list of files and offsets. JMarc
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
John If LyX locked files which were open in a still running LyX John process, that would have saved me some confusion. Yes, but I am sure this can cause a lot of confusion too... I am not sure why this would cause confusion. You could have a dialog box warning that Another LyX window has this file open and offer some of the following alternatives: * Do not open. * Open read only. * Open anyway. * Attempt to kill other LyX window. -- John C. McCabe-Dansted Master's Student
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
> John> If LyX locked files which were open in a still running LyX > John> process, that would have saved me some confusion. > > Yes, but I am sure this can cause a lot of confusion too... I am not sure why this would cause confusion. You could have a dialog box warning that "Another LyX window has this file open" and offer some of the following alternatives: * Do not open. * Open read only. * Open anyway. * Attempt to kill other LyX window. -- John C. McCabe-Dansted Master's Student
[another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
John == John McCabe-Dansted [EMAIL PROTECTED] writes:
Sure, the extra trouble only ever occur for power users.
John Perhaps we could have a new minibuffer command save-unchanged
John which would save the document even if it is unchanged. Such
John power users could replace save with save-unchanged in their
John .bind files etc.
It is easiest to do an explicit change when needed.
John If LyX locked files which were open in a still running LyX
John process, that would have saved me some confusion.
Yes, but I am sure this can cause a lot of confusion too...
Anyway, I have an additional patch for this bug. Anyone disagrees?
JMarc
Index: src/ChangeLog
===
--- src/ChangeLog (revision 13424)
+++ src/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2006-03-20 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * lyxfunc.C (getStatus): always allow saving unnamed buffers (bug
+ 2313 cont'd).
+
2006-03-16 Jürgen Spitzmüller [EMAIL PROTECTED]
* text.C (delete): adjust cursor after backspace in change tracking
Index: src/lyxfunc.C
===
--- src/lyxfunc.C (revision 13424)
+++ src/lyxfunc.C (working copy)
@@ -541,7 +541,8 @@ FuncStatus LyXFunc::getStatus(FuncReques
}
case LFUN_MENUWRITE: {
- enable = !view()-buffer()-isClean();
+ enable = view()-buffer()-isUnnamed()
+ || !view()-buffer()-isClean();
break;
}
[another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
> "John" == John McCabe-Dansted <[EMAIL PROTECTED]> writes:
>> Sure, the "extra trouble" only ever occur for power users.
John> Perhaps we could have a new minibuffer command save-unchanged
John> which would save the document even if it is unchanged. Such
John> power users could replace "save" with "save-unchanged" in their
John> .bind files etc.
It is easiest to do an explicit change when needed.
John> If LyX locked files which were open in a still running LyX
John> process, that would have saved me some confusion.
Yes, but I am sure this can cause a lot of confusion too...
Anyway, I have an additional patch for this bug. Anyone disagrees?
JMarc
Index: src/ChangeLog
===
--- src/ChangeLog (revision 13424)
+++ src/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2006-03-20 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * lyxfunc.C (getStatus): always allow saving unnamed buffers (bug
+ 2313 cont'd).
+
2006-03-16 Jürgen Spitzmüller <[EMAIL PROTECTED]>
* text.C (delete): adjust cursor after backspace in change tracking
Index: src/lyxfunc.C
===
--- src/lyxfunc.C (revision 13424)
+++ src/lyxfunc.C (working copy)
@@ -541,7 +541,8 @@ FuncStatus LyXFunc::getStatus(FuncReques
}
case LFUN_MENUWRITE: {
- enable = !view()->buffer()->isClean();
+ enable = view()->buffer()->isUnnamed()
+ || !view()->buffer()->isClean();
break;
}
Another patch for lyx.spec.in
Hi folks, Here is another set of cleanups for the lyx.spec.in: Please apply. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92) Index: development/ChangeLog === RCS file: /cvs/lyx/lyx-devel/development/ChangeLog,v retrieving revision 1.9 diff -u -u -r1.9 ChangeLog --- development/ChangeLog 2001/08/05 22:15:41 1.9 +++ development/ChangeLog 2001/08/06 06:53:24 @@ -1,3 +1,7 @@ +2001-08-05 Kayvan A. Sylvan [EMAIL PROTECTED] + + * lyx.spec.in: More cleanups and wording changes. + 2001-08-03 Kayvan Sylvan [EMAIL PROTECTED] * lyx.spec.in: Integrate tetex-lyx into main RPM. Index: development/lyx.spec.in === RCS file: /cvs/lyx/lyx-devel/development/lyx.spec.in,v retrieving revision 1.10 diff -u -u -r1.10 lyx.spec.in --- development/lyx.spec.in 2001/08/05 22:15:41 1.10 +++ development/lyx.spec.in 2001/08/06 06:53:24 @@ -1,4 +1,4 @@ -Summary: A WYSYWIG frontend to LaTeX +Summary: A WYSIWYM (What You See Is What You Mean) frontend to LaTeX Name: @PACKAGE@ Version: @VERSION@ Release: 1 @@ -14,25 +14,22 @@ Obsoletes: tetex-lyx %description -LyX is a modern approach of writing documents with a computer -which breaks with the tradition of the obsolete typewriter -concept. It is designed for people who want a professional -output with a minimum of time and effort, without becoming specia- -lists in typesetting. Compared to common word processors LyX -will increase the productivity a lot, since most of the type- -setting will be done by the computer, not the author. With LyX -the author can concentrate on the contents of his writing, -since the computer will take care of the look. - -%package -n tetex-lyx -Summary: Files for LyX packaged for tetex -Requires: lyx -Group: Applications/Publishing - -%description -n tetex-lyx -This package contains the LaTeX files for LyX installed in the normal -place that the Redhat tetex package is installed and would see it. +LyX is a modern approach to writing documents which breaks with the +obsolete typewriter paradigm of most other document preparation +systems. + +It is designed for people who want professional quality output +with a minimum of time and effort, without becoming specialists in +typesetting. + +The major innovation in LyX is WYSIWYM (What You See Is What You Mean). +That is, the author focuses on content, not on the details of formatting. +This allows for greater productivity, and leaves the final typesetting +to the backends (like LaTeX) that are specifically designed for the task. +With LyX, the author can concentrate on the contents of his writing, +and let the computer take care of the rest. + %prep %setup @@ -107,7 +104,6 @@ %attr(-,root,root) %doc ABOUT-NLS ANNOUNCE COPYING %attr(-,root,root) %doc README UPGRADING ChangeLog NEWS %attr(-,root,root) %doc lib/CREDITS README.reLyX - %attr(-,root,root) /usr/bin/* %attr(-,root,root) /usr/man/* %attr(-,root,root) /usr/share/locale/*/LC_MESSAGES/*
Another patch for lyx.spec.in
Hi folks, Here is another set of cleanups for the lyx.spec.in: Please apply. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92) Index: development/ChangeLog === RCS file: /cvs/lyx/lyx-devel/development/ChangeLog,v retrieving revision 1.9 diff -u -u -r1.9 ChangeLog --- development/ChangeLog 2001/08/05 22:15:41 1.9 +++ development/ChangeLog 2001/08/06 06:53:24 @@ -1,3 +1,7 @@ +2001-08-05 Kayvan A. Sylvan <[EMAIL PROTECTED]> + + * lyx.spec.in: More cleanups and wording changes. + 2001-08-03 Kayvan Sylvan <[EMAIL PROTECTED]> * lyx.spec.in: Integrate tetex-lyx into main RPM. Index: development/lyx.spec.in === RCS file: /cvs/lyx/lyx-devel/development/lyx.spec.in,v retrieving revision 1.10 diff -u -u -r1.10 lyx.spec.in --- development/lyx.spec.in 2001/08/05 22:15:41 1.10 +++ development/lyx.spec.in 2001/08/06 06:53:24 @@ -1,4 +1,4 @@ -Summary: A WYSYWIG frontend to LaTeX +Summary: A WYSIWYM (What You See Is What You Mean) frontend to LaTeX Name: @PACKAGE@ Version: @VERSION@ Release: 1 @@ -14,25 +14,22 @@ Obsoletes: tetex-lyx %description -LyX is a modern approach of writing documents with a computer -which breaks with the tradition of the obsolete typewriter -concept. It is designed for people who want a professional -output with a minimum of time and effort, without becoming specia- -lists in typesetting. Compared to common word processors LyX -will increase the productivity a lot, since most of the type- -setting will be done by the computer, not the author. With LyX -the author can concentrate on the contents of his writing, -since the computer will take care of the look. - -%package -n tetex-lyx -Summary: Files for LyX packaged for tetex -Requires: lyx -Group: Applications/Publishing - -%description -n tetex-lyx -This package contains the LaTeX files for LyX installed in the normal -place that the Redhat tetex package is installed and would see it. +LyX is a modern approach to writing documents which breaks with the +obsolete "typewriter paradigm" of most other document preparation +systems. + +It is designed for people who want professional quality output +with a minimum of time and effort, without becoming specialists in +typesetting. + +The major innovation in LyX is WYSIWYM (What You See Is What You Mean). +That is, the author focuses on content, not on the details of formatting. +This allows for greater productivity, and leaves the final typesetting +to the backends (like LaTeX) that are specifically designed for the task. +With LyX, the author can concentrate on the contents of his writing, +and let the computer take care of the rest. + %prep %setup @@ -107,7 +104,6 @@ %attr(-,root,root) %doc ABOUT-NLS ANNOUNCE COPYING %attr(-,root,root) %doc README UPGRADING ChangeLog NEWS %attr(-,root,root) %doc lib/CREDITS README.reLyX - %attr(-,root,root) /usr/bin/* %attr(-,root,root) /usr/man/* %attr(-,root,root) /usr/share/locale/*/LC_MESSAGES/*
Re: another patch...
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes: Asger Regarding improving the performance: I can only recommend using Asger gprof. It's very easy, and it really helps when you want to Asger find and address bottlenecks. Yes, profiling is often a better idea than trying to guess where time is lost. Nevertheless, since we know without profiling that font loading is terribly slow, couldn't we cache the font metrics between runs like wine (for example) does? I'm sure the gain would be important. JMarc
Re: another patch...
"Mike" == [EMAIL PROTECTED] writes: Mike On 5 Mar 2001, Jean-Marc Lasgouttes wrote: I tried the "benchmark" a bit here, and the times in successive rune fluctuate enough that I do not see how you can interpret them... Mike This wins the "Cool Typo" award. When reading your (the Mike developers') discussions of compilers, pragmas, etc. my head Mike spins enough that you may as well be benchmarking in "successive Mike runes" Yes, that's what we are doing actually, but don't tell! JMarc
Re: another patch...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes: | | Asger Regarding improving the performance: I can only recommend using | Asger gprof. It's very easy, and it really helps when you want to | Asger find and address bottlenecks. | | Yes, profiling is often a better idea than trying to guess where time | is lost. | | Nevertheless, since we know without profiling that font loading is | terribly slow, couldn't we cache the font metrics between runs like | wine (for example) does? I'm sure the gain would be important. I think my lazy generation of LyXText could help on that. then we should only load the font metrics when first needed. Lgb
Re: another patch...
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars I think my lazy generation of LyXText could help on that. then Lars we should only load the font metrics when first needed. Stupid question: are we forced to load the whole font metrics to use a font? If not, caching would be a gain. JMarc
Re: another patch...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: | | Lars I think my lazy generation of LyXText could help on that. then | Lars we should only load the font metrics when first needed. | | Stupid question: are we forced to load the whole font metrics to use a | font? If not, caching would be a gain. Yes, I belive so. part of the unicode addition to XFree86 have some changes to this, but I have no details. Lgb
Re: another patch...
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes: Asger> Regarding improving the performance: I can only recommend using Asger> gprof. It's very easy, and it really helps when you want to Asger> find and address bottlenecks. Yes, profiling is often a better idea than trying to guess where time is lost. Nevertheless, since we know without profiling that font loading is terribly slow, couldn't we cache the font metrics between runs like wine (for example) does? I'm sure the gain would be important. JMarc
Re: another patch...
> "Mike" == <[EMAIL PROTECTED]> writes: Mike> On 5 Mar 2001, Jean-Marc Lasgouttes wrote: >> I tried the "benchmark" a bit here, and the times in successive >> rune fluctuate enough that I do not see how you can interpret >> them... Mike> This wins the "Cool Typo" award. When reading your (the Mike> developers') discussions of compilers, pragmas, etc. my head Mike> spins enough that you may as well be benchmarking in "successive Mike> runes" Yes, that's what we are doing actually, but don't tell! JMarc
Re: another patch...
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes: | | Asger> Regarding improving the performance: I can only recommend using | Asger> gprof. It's very easy, and it really helps when you want to | Asger> find and address bottlenecks. | | Yes, profiling is often a better idea than trying to guess where time | is lost. | | Nevertheless, since we know without profiling that font loading is | terribly slow, couldn't we cache the font metrics between runs like | wine (for example) does? I'm sure the gain would be important. I think my lazy generation of LyXText could help on that. then we should only load the font metrics when first needed. Lgb
Re: another patch...
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I think my lazy generation of LyXText could help on that. then Lars> we should only load the font metrics when first needed. Stupid question: are we forced to load the whole font metrics to use a font? If not, caching would be a gain. JMarc
Re: another patch...
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> I think my lazy generation of LyXText could help on that. then | Lars> we should only load the font metrics when first needed. | | Stupid question: are we forced to load the whole font metrics to use a | font? If not, caching would be a gain. Yes, I belive so. part of the unicode addition to XFree86 have some changes to this, but I have no details. Lgb
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes: | On Sun, Mar 04, 2001 at 07:58:15PM +0100, Lars Gullik Bjnnes wrote: | | | This patch includes the previous one and adds the same memore saving | as with the paragraph parameters, but now also for LyXFont. | | It raises binary size a bit more than I would like, but the memory | footprint for Userguide is now ~500 Kb. | | Comments? | | With the new patch, the Userguide loads very slowly: ~18 sec | while with the old code (or the old patch) the UG loads in ~7sec | (timed with 'time lyx -x lyx-quit UserGuide.lyx'). Yes, I see the same here. So we have to decide if this is a slow down that we can live with. (on the cell phone the numbers above came out as 218 and 27 and I got really worried...) btw. by also having language in fontbits we can save 4 bytes more for each LyXFont in use. This brings the size of LyXFont down from 44 bytes to 8 bytes. Lgb
Re: another patch...
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Yes, I see the same here. So we have to decide if this is a slow Lars down that we can live with. (on the cell phone the numbers above Lars came out as 218 and 27 and I got really worried...) Where does the slowdown come from? The ShareContainer::get method? Concerning this ShareContainer template, an obvious question: isn't there a better container than vector for this kind of stuff (a map?). Or could we order the contents of the container so that the most requested items come first? All in all, the patch looks nice, but the slow down (especially on UserGuide.lyx, which is a useful file in its own right) is a problem... JMarc
Re: another patch...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: | | Lars Yes, I see the same here. So we have to decide if this is a slow | Lars down that we can live with. (on the cell phone the numbers above | Lars came out as 218 and 27 and I got really worried...) | | Where does the slowdown come from? The ShareContainer::get method? | Concerning this ShareContainer template, an obvious question: isn't | there a better container than vector for this kind of stuff (a map?). | Or could we order the contents of the container so that the most | requested items come first? A map is not very good since we don't have a obvious key (for the same reason a hash_map would be hard to use since a hash function would be hard to get fast/right/uniue). I agree that the linear search is not good. (and this is what causes the slowdown I belive, (also that we clean the container very often)) Prefferably the clean should be moved into the get, but I am a bit afraid that this can cause wrong behaviour, I have to think a bit more on that. Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Yes, I see the same here. So we have to decide if this is a slow
Lars down that we can live with. (on the cell phone the numbers above
Lars came out as 218 and 27 and I got really worried...)
Where does the slowdown come from? The ShareContainer::get method?
Concerning this ShareContainer template, an obvious question: isn't
there a better container than vector for this kind of stuff (a map?).
Or could we order the contents of the container so that the most
requested items come first?
The problem is that the data in a LyXText instance is changed frequently
(in the LyXParagraph::GetFont and LyXText::GetFont methods).
The solution is perhaps to keep the LyXFont class unchanged, but in
LyXParagraph::FontTable store a boost::shared_ptrLyXFont
instead of a LyXFont.
btw. by also having language in fontbits we can save 4 bytes more for
each LyXFont in use. This brings the size of LyXFont down from 44
bytes to 8 bytes.
Another option (without using shared_ptr) is to change the members in
FontBits to chars (i.e. struct FontBits { char family; char series; ...})
This is a bit ugly, but at least it will give a memory reduction, without a
slowdown.
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes:
| On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
| "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
|
| Lars Yes, I see the same here. So we have to decide if this is a slow
| Lars down that we can live with. (on the cell phone the numbers above
| Lars came out as 218 and 27 and I got really worried...)
|
| Where does the slowdown come from? The ShareContainer::get method?
| Concerning this ShareContainer template, an obvious question: isn't
| there a better container than vector for this kind of stuff (a map?).
| Or could we order the contents of the container so that the most
| requested items come first?
|
| The problem is that the data in a LyXText instance is changed frequently
| (in the LyXParagraph::GetFont and LyXText::GetFont methods).
| The solution is perhaps to keep the LyXFont class unchanged, but in
| LyXParagraph::FontTable store a boost::shared_ptrLyXFont
| instead of a LyXFont.
afaics it will be a lot harder then to localize the SharedContainer
(functionality that will be needed to really save anything.)
| btw. by also having language in fontbits we can save 4 bytes more for
| each LyXFont in use. This brings the size of LyXFont down from 44
| bytes to 8 bytes.
|
| Another option (without using shared_ptr) is to change the members in
| FontBits to chars (i.e. struct FontBits { char family; char series; ...})
| This is a bit ugly, but at least it will give a memory reduction, without a
| slowdown.
Oh, we had that earlier, the code was close to impossible to maintain,
won't happen. and I'd hate to loose the type information. btw. clever
compilers are free to use a byte for most of those enums.
Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 01:24:24PM +0100, Lars Gullik Bjønnes wrote:
| The problem is that the data in a LyXText instance is changed frequently
| (in the LyXParagraph::GetFont and LyXText::GetFont methods).
| The solution is perhaps to keep the LyXFont class unchanged, but in
| LyXParagraph::FontTable store a boost::shared_ptrLyXFont
| instead of a LyXFont.
afaics it will be a lot harder then to localize the SharedContainer
(functionality that will be needed to really save anything.)
Why?
| Another option (without using shared_ptr) is to change the members in
| FontBits to chars (i.e. struct FontBits { char family; char series; ...})
| This is a bit ugly, but at least it will give a memory reduction, without a
| slowdown.
Oh, we had that earlier, the code was close to impossible to maintain,
won't happen. and I'd hate to loose the type information. btw. clever
compilers are free to use a byte for most of those enums.
IIRC, we had something else: all the data was packed into a single unsigned
int, and that was indeed horrible.
With my suggestion it is not harder to maintain than the current code.
And you don't loose the type information because the interface method
(family(), series() etc.) do return the correct type.
Re: another patch...
[EMAIL PROTECTED] (Lars Gullik Bjnnes) writes: | A map is not very good since we don't have a obvious key (for the same | reason a hash_map would be hard to use since a hash function would be | hard to get fast/right/uniue). | | I agree that the linear search is not good. (and this is what causes | the slowdown I belive, (also that we clean the container very | often)) we can sort the vector on the use_count of the shared_ptr. Then the items that is used by the most will be found first. Hmm... but we cannot use any of the other std::containers... but we can perhaps use a priority_queue (with a deque underneath). I'll do some other small changes first and then I will try that. I will send new patches as I make progress. Lgb
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes: | Oh, we had that earlier, the code was close to impossible to maintain, | won't happen. and I'd hate to loose the type information. btw. clever | compilers are free to use a byte for most of those enums. | | IIRC, we had something else: all the data was packed into a single unsigned | int, and that was indeed horrible. (I know) | With my suggestion it is not harder to maintain than the current code. | And you don't loose the type information because the interface method | (family(), series() etc.) do return the correct type. You loose type information inside the LyXFont class. besides, I think I can speed it up quite a lot by changing when clean is done, and using a bit more clever container. Let's do that first. Lgb
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes: | With the new patch, the Userguide loads very slowly: ~18 sec | while with the old code (or the old patch) the UG loads in ~7sec | (timed with 'time lyx -x lyx-quit UserGuide.lyx'). time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx About to handle -x 'lyx-quit' real0m8.495s user0m5.880s sys 0m0.030s On a PIII 700Mhz (with primed cache) without the primed cache it is ~13s. This is by moving the clean to another place. Lgb
Re: another patch...
[EMAIL PROTECTED] (Lars Gullik Bjnnes) writes: | time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x 'lyx-quit' | | real0m8.495s | user0m5.880s | sys 0m0.030s | | On a PIII 700Mhz (with primed cache) With braindead use of push_heap: time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx About to handle -x 'lyx-quit' real0m8.515s user0m6.010s sys 0m0.050s Lgb
Re: another patch...
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | time ./src/lyx -x Lars lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x Lars 'lyx-quit' | | real 0m8.495s | user 0m5.880s | sys 0m0.030s | | Lars On a PIII 700Mhz (with primed cache) Lars With braindead use of push_heap: Lars time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx Lars About to handle -x 'lyx-quit' Lars real 0m8.515s user 0m6.010s sys 0m0.050s I tried the "benchmark" a bit here, and the times in successive rune fluctuate enough that I do not see how you can interpret them... JMarc
Re: another patch...
"Jean-Marc" == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc I tried the "benchmark" a bit here, and the times in Jean-Marc successive rune fluctuate enough that I do not see how you Jean-Marc can interpret them... Something like time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx seems to give more consistent results across runs JMarc
Re: another patch...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: | | Lars [EMAIL PROTECTED] (Lars Gullik Bjnnes) writes: | time ./src/lyx -x | Lars lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x | Lars 'lyx-quit' | | real 0m8.495s | user 0m5.880s | sys 0m0.030s | | | Lars On a PIII 700Mhz (with primed cache) | | Lars With braindead use of push_heap: | | Lars time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx | Lars About to handle -x 'lyx-quit' | | Lars real 0m8.515s user 0m6.010s sys 0m0.050s | | I tried the "benchmark" a bit here, and the times in successive rune | fluctuate enough that I do not see how you can interpret them... I never tried more than two runs in a row :-) Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjønnes wrote:
time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
About to handle -x 'lyx-quit'
real0m8.515s
user0m6.010s
sys 0m0.050s
It still looks slow.
I still don't understand why we can't use my previous suggestion:
class FontTable {
public:
FontTable(size_type p, LyXFont const f) {
font_ = container.get(f);
container.clean();
}
LyXFont const font();
size_type pos();
private:
boost::shared_ptrLyXFont font_;
size_type pos_;
static ShareContainerLyXFont container;
};
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes:
| On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjnnes wrote:
| time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
| About to handle -x 'lyx-quit'
|
| real0m8.515s
| user0m6.010s
| sys 0m0.050s
|
| It still looks slow.
|
| I still don't understand why we can't use my previous suggestion:
|
| class FontTable {
| public:
| FontTable(size_type p, LyXFont const f) {
| font_ = container.get(f);
| container.clean();
| }
| LyXFont const font();
| size_type pos();
| private:
| boost::shared_ptrLyXFont font_;
| size_type pos_;
| static ShareContainerLyXFont container;
| };
Because I want to see if I can make the broader case faster first.
And your solution would benefit from this too.
Lgb
Re: another patch...
On 05-Mar-2001 Jean-Marc Lasgouttes wrote: Something like time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx seems to give more consistent results across runs But this doesn't load a LyXText instance, does it? And there the Fonts are used most, isn't it? Jrgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jrgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ By failing to prepare, you are preparing to fail.
Re: another patch...
On Mon, Mar 05, 2001 at 03:28:11PM +0100, Jean-Marc Lasgouttes wrote: "Jean-Marc" == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc I tried the "benchmark" a bit here, and the times in Jean-Marc successive rune fluctuate enough that I do not see how you Jean-Marc can interpret them... Something like time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx seems to give more consistent results across runs But this will not time the rendering pipeline (spiting the text to rows etc.) which is the part that causes the slowdown (I think).
Re: another patch...
Regarding improving the performance: I can only recommend using gprof. It's very easy, and it really helps when you want to find and address bottlenecks. Also, I must confess that it was me that introduced the ugly integer packed representation of the font information a long time ago. That was done because profiling showed it to be a huge gain, and at that point in time, it did in fact help. I understand that the structure is different today, so hopefully you won't have to revert to such a scheme again. Greets, Asger
Re: another patch...
On 5 Mar 2001, Jean-Marc Lasgouttes wrote: I tried the "benchmark" a bit here, and the times in successive rune fluctuate enough that I do not see how you can interpret them... This wins the "Cool Typo" award. When reading your (the developers') discussions of compilers, pragmas, etc. my head spins enough that you may as well be benchmarking in "successive runes", because I am certain that you are practicing spells and engaged in the black arts. Maybe it's time to support Peter Wilson's excellent archaic fonts, e.g. ctan:/tex-archive/fonts/archaic/runic. :-) Happy Monday! Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Sun, Mar 04, 2001 at 07:58:15PM +0100, Lars Gullik Bjønnes wrote: | > | > | > This patch includes the previous one and adds the same memore saving | > as with the paragraph parameters, but now also for LyXFont. | > | > It raises binary size a bit more than I would like, but the memory | > footprint for Userguide is now ~500 Kb. | > | > Comments? | | With the new patch, the Userguide loads very slowly: ~18 sec | while with the old code (or the old patch) the UG loads in ~7sec | (timed with 'time lyx -x lyx-quit UserGuide.lyx'). Yes, I see the same here. So we have to decide if this is a slow down that we can live with. (on the cell phone the numbers above came out as 218 and 27 and I got really worried...) btw. by also having language in fontbits we can save 4 bytes more for each LyXFont in use. This brings the size of LyXFont down from 44 bytes to 8 bytes. Lgb
Re: another patch...
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Yes, I see the same here. So we have to decide if this is a slow Lars> down that we can live with. (on the cell phone the numbers above Lars> came out as 218 and 27 and I got really worried...) Where does the slowdown come from? The ShareContainer::get method? Concerning this ShareContainer template, an obvious question: isn't there a better container than vector for this kind of stuff (a map?). Or could we order the contents of the container so that the most requested items come first? All in all, the patch looks nice, but the slow down (especially on UserGuide.lyx, which is a useful file in its own right) is a problem... JMarc
Re: another patch...
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Yes, I see the same here. So we have to decide if this is a slow | Lars> down that we can live with. (on the cell phone the numbers above | Lars> came out as 218 and 27 and I got really worried...) | | Where does the slowdown come from? The ShareContainer::get method? | Concerning this ShareContainer template, an obvious question: isn't | there a better container than vector for this kind of stuff (a map?). | Or could we order the contents of the container so that the most | requested items come first? A map is not very good since we don't have a obvious key (for the same reason a hash_map would be hard to use since a hash function would be hard to get fast/right/uniue). I agree that the linear search is not good. (and this is what causes the slowdown I belive, (also that we clean the container very often)) Prefferably the clean should be moved into the get, but I am a bit afraid that this can cause wrong behaviour, I have to think a bit more on that. Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> Yes, I see the same here. So we have to decide if this is a slow
> Lars> down that we can live with. (on the cell phone the numbers above
> Lars> came out as 218 and 27 and I got really worried...)
>
> Where does the slowdown come from? The ShareContainer::get method?
> Concerning this ShareContainer template, an obvious question: isn't
> there a better container than vector for this kind of stuff (a map?).
> Or could we order the contents of the container so that the most
> requested items come first?
The problem is that the data in a LyXText instance is changed frequently
(in the LyXParagraph::GetFont and LyXText::GetFont methods).
The solution is perhaps to keep the LyXFont class unchanged, but in
LyXParagraph::FontTable store a boost::shared_ptr
instead of a LyXFont.
> btw. by also having language in fontbits we can save 4 bytes more for
> each LyXFont in use. This brings the size of LyXFont down from 44
> bytes to 8 bytes.
Another option (without using shared_ptr) is to change the members in
FontBits to chars (i.e. struct FontBits { char family; char series; ...})
This is a bit ugly, but at least it will give a memory reduction, without a
slowdown.
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
| > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| >
| > Lars> Yes, I see the same here. So we have to decide if this is a slow
| > Lars> down that we can live with. (on the cell phone the numbers above
| > Lars> came out as 218 and 27 and I got really worried...)
| >
| > Where does the slowdown come from? The ShareContainer::get method?
| > Concerning this ShareContainer template, an obvious question: isn't
| > there a better container than vector for this kind of stuff (a map?).
| > Or could we order the contents of the container so that the most
| > requested items come first?
|
| The problem is that the data in a LyXText instance is changed frequently
| (in the LyXParagraph::GetFont and LyXText::GetFont methods).
| The solution is perhaps to keep the LyXFont class unchanged, but in
| LyXParagraph::FontTable store a boost::shared_ptr
| instead of a LyXFont.
afaics it will be a lot harder then to localize the SharedContainer
(functionality that will be needed to really save anything.)
| > btw. by also having language in fontbits we can save 4 bytes more for
| > each LyXFont in use. This brings the size of LyXFont down from 44
| > bytes to 8 bytes.
|
| Another option (without using shared_ptr) is to change the members in
| FontBits to chars (i.e. struct FontBits { char family; char series; ...})
| This is a bit ugly, but at least it will give a memory reduction, without a
| slowdown.
Oh, we had that earlier, the code was close to impossible to maintain,
won't happen. and I'd hate to loose the type information. btw. clever
compilers are free to use a byte for most of those enums.
Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 01:24:24PM +0100, Lars Gullik Bjønnes wrote:
> | The problem is that the data in a LyXText instance is changed frequently
> | (in the LyXParagraph::GetFont and LyXText::GetFont methods).
> | The solution is perhaps to keep the LyXFont class unchanged, but in
> | LyXParagraph::FontTable store a boost::shared_ptr
> | instead of a LyXFont.
>
> afaics it will be a lot harder then to localize the SharedContainer
> (functionality that will be needed to really save anything.)
Why?
> | Another option (without using shared_ptr) is to change the members in
> | FontBits to chars (i.e. struct FontBits { char family; char series; ...})
> | This is a bit ugly, but at least it will give a memory reduction, without a
> | slowdown.
>
> Oh, we had that earlier, the code was close to impossible to maintain,
> won't happen. and I'd hate to loose the type information. btw. clever
> compilers are free to use a byte for most of those enums.
IIRC, we had something else: all the data was packed into a single unsigned
int, and that was indeed horrible.
With my suggestion it is not harder to maintain than the current code.
And you don't loose the type information because the interface method
(family(), series() etc.) do return the correct type.
Re: another patch...
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | A map is not very good since we don't have a obvious key (for the same | reason a hash_map would be hard to use since a hash function would be | hard to get fast/right/uniue). | | I agree that the linear search is not good. (and this is what causes | the slowdown I belive, (also that we clean the container very | often)) we can sort the vector on the use_count of the shared_ptr. Then the items that is used by the most will be found first. Hmm... but we cannot use any of the other std::containers... but we can perhaps use a priority_queue (with a deque underneath). I'll do some other small changes first and then I will try that. I will send new patches as I make progress. Lgb
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes: | > Oh, we had that earlier, the code was close to impossible to maintain, | > won't happen. and I'd hate to loose the type information. btw. clever | > compilers are free to use a byte for most of those enums. | | IIRC, we had something else: all the data was packed into a single unsigned | int, and that was indeed horrible. (I know) | With my suggestion it is not harder to maintain than the current code. | And you don't loose the type information because the interface method | (family(), series() etc.) do return the correct type. You loose type information inside the LyXFont class. besides, I think I can speed it up quite a lot by changing when clean is done, and using a bit more clever container. Let's do that first. Lgb
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes: | With the new patch, the Userguide loads very slowly: ~18 sec | while with the old code (or the old patch) the UG loads in ~7sec | (timed with 'time lyx -x lyx-quit UserGuide.lyx'). time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx About to handle -x 'lyx-quit' real0m8.495s user0m5.880s sys 0m0.030s On a PIII 700Mhz (with primed cache) without the primed cache it is ~13s. This is by moving the clean to another place. Lgb
Re: another patch...
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x 'lyx-quit' | | real0m8.495s | user0m5.880s | sys 0m0.030s | | On a PIII 700Mhz (with primed cache) With braindead use of push_heap: time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx About to handle -x 'lyx-quit' real0m8.515s user0m6.010s sys 0m0.050s Lgb
Re: another patch...
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | time ./src/lyx -x Lars> lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x Lars> 'lyx-quit' | | real 0m8.495s | user 0m5.880s | sys 0m0.030s | | Lars> On a PIII 700Mhz (with primed cache) Lars> With braindead use of push_heap: Lars> time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx Lars> About to handle -x 'lyx-quit' Lars> real 0m8.515s user 0m6.010s sys 0m0.050s I tried the "benchmark" a bit here, and the times in successive rune fluctuate enough that I do not see how you can interpret them... JMarc
Re: another patch...
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> I tried the "benchmark" a bit here, and the times in Jean-Marc> successive rune fluctuate enough that I do not see how you Jean-Marc> can interpret them... Something like time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx seems to give more consistent results across runs JMarc
Re: another patch...
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | time ./src/lyx -x | Lars> lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x | Lars> 'lyx-quit' | | real 0m8.495s | user 0m5.880s | sys 0m0.030s | | | Lars> On a PIII 700Mhz (with primed cache) | | Lars> With braindead use of push_heap: | | Lars> time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx | Lars> About to handle -x 'lyx-quit' | | Lars> real 0m8.515s user 0m6.010s sys 0m0.050s | | I tried the "benchmark" a bit here, and the times in successive rune | fluctuate enough that I do not see how you can interpret them... I never tried more than two runs in a row :-) Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjønnes wrote:
> time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
> About to handle -x 'lyx-quit'
>
> real0m8.515s
> user0m6.010s
> sys 0m0.050s
It still looks slow.
I still don't understand why we can't use my previous suggestion:
class FontTable {
public:
FontTable(size_type p, LyXFont const & f) {
font_ = container.get(f);
container.clean();
}
LyXFont const & font();
size_type pos();
private:
boost::shared_ptr font_;
size_type pos_;
static ShareContainer container;
};
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjønnes wrote:
| > time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
| > About to handle -x 'lyx-quit'
| >
| > real0m8.515s
| > user0m6.010s
| > sys 0m0.050s
|
| It still looks slow.
|
| I still don't understand why we can't use my previous suggestion:
|
| class FontTable {
| public:
| FontTable(size_type p, LyXFont const & f) {
| font_ = container.get(f);
| container.clean();
| }
| LyXFont const & font();
| size_type pos();
| private:
| boost::shared_ptr font_;
| size_type pos_;
| static ShareContainer container;
| };
Because I want to see if I can make the broader case faster first.
And your solution would benefit from this too.
Lgb
Re: another patch...
On 05-Mar-2001 Jean-Marc Lasgouttes wrote: > Something like > time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx > seems to give more consistent results across runs But this doesn't load a LyXText instance, does it? And there the Fonts are used most, isn't it? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ By failing to prepare, you are preparing to fail.
Re: another patch...
On Mon, Mar 05, 2001 at 03:28:11PM +0100, Jean-Marc Lasgouttes wrote: > > "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > Jean-Marc> I tried the "benchmark" a bit here, and the times in > Jean-Marc> successive rune fluctuate enough that I do not see how you > Jean-Marc> can interpret them... > > Something like > time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx > seems to give more consistent results across runs But this will not time the rendering pipeline (spiting the text to rows etc.) which is the part that causes the slowdown (I think).
