[patch] Space displayed after macro, #3705
Here is a patch for http://bugzilla.lyx.org/show_bug.cgi?id=3705. It
adds the kerning method to a macro to inherit the kerning from the
expanded form. Moreover the marker metrics calls are remove as they
are not drawn anyway.
Stefan
Index: src/mathed/MathMacro.h
===
--- src/mathed/MathMacro.h (Revision 18774)
+++ src/mathed/MathMacro.h (Arbeitskopie)
@@ -54,6 +54,8 @@
///
docstring name() const;
///
+ int kerning() const { return kerning_; }
+ ///
void setExpansion(MathData const exp, MathData const args) const;
///
@@ -85,6 +87,8 @@
mutable MacroData macroBackup_;
///
mutable bool editing_;
+ ///
+ mutable int kerning_;
};
Index: src/mathed/MathMacro.cpp
===
--- src/mathed/MathMacro.cpp(Revision 18774)
+++ src/mathed/MathMacro.cpp(Arbeitskopie)
@@ -44,6 +44,8 @@
bool metrics(MetricsInfo mi, Dimension dim) const;
///
void draw(PainterInfo , int x, int y) const;
+ ///
+ int kerning() const { return mathMacro_.cell(idx_).kerning(); }
private:
std::auto_ptrInset doClone() const;
@@ -65,7 +67,6 @@
macro.unlock();
mathMacro_.cell(idx_).metrics(mi, dim);
macro.lock();
- metricsMarkers2(dim);
if (dim_ == dim)
return false;
dim_ = dim;
@@ -114,6 +115,7 @@
bool MathMacro::metrics(MetricsInfo mi, Dimension dim) const
{
+ kerning_ = 0;
if (!MacroTable::globalMacros().has(name())) {
mathed_string_dim(mi.base.font, Unknown: + name(), dim);
} else {
@@ -143,10 +145,10 @@
macro.lock();
expanded_.metrics(mi, dim);
macro.unlock();
+ kerning_ = expanded_.kerning();
editing_ = false;
}
}
- metricsMarkers2(dim);
if (dim_ == dim)
return false;
dim_ = dim;
@@ -199,7 +201,6 @@
if (editing_ != editing(pi.base.bv) || macroBackup_ != macro)
pi.base.bv-cursor().updateFlags(Update::Force);
}
- drawMarkers2(pi, x, y);
}
macrospacearound.patch
Description: Binary data
PGP.sig
Description: Signierter Teil der Nachricht
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Hi,
My comments are below
Miki
3. If I have a Hebrew paragraph with an English word like
? English ? ?
and I type continuously, the spaces are Hebrew. Now if I try to
continue the Hebrew to the right of the English word, but after the
Hebrew space, as to continue typing, I can't: If I am in English mode
and I press F12 (bound to language hebrew), the cursor jumps to the
left of the English word. If I was already in hebrew (if the cursor was
resting on a hebrew word before and then I moved it to this position
with the mouse), then it's ok.
This is correct. If you move to the right of the english through the
english, then at the end you are still considered to be in English, at
the end of the english; so switching to hebrew should move you to the
left of the english. You can do what you want by moving to the beginning
of the english, and then move back one more, that'll bring you to the
space before the english; then if you move one Left, you'll be after the
space, but still in hebrew. Typing in hebrew will then work as you want
it to.
What you say is correct, and I have found that out, but it is not
intuitive
and takes learning lyx's behavior.
Also, when you just land there with the mouse, you have the same
problem.
Can you think of a sane way to solve this?
What do you want LyX to do: to say that if you've been typing in english
and then switch the language to hebrew, that it should jump back to before
the english, and continue inserting the hebrew there? 'cause I think
that's what would be necessary to do what you want in this case --- but
then just plain typing in would be a real pain: you type some hebrew, want
to insert a word in english so you switch to english, type the word, then
switch back to hebrew (you want to continue typing ---
after the english word, of course) and find yourself before the english
word!
I don't see any way out. And BTW, I'm not sure --- but I don't think that
visual mode will solve this, either...
I would like lyx to be visual, and I think it will solve this problem, since
the cursor will STAY PUT in the location it is in without jumping anywhere.
In latex, you will have \L's and \R's all over the place, and you can clean
that up later - maybe when saving, maybe when leaving the row. I don't
know enough about what lyx does (I wanted to get into it but I lack the
time, maybe in the future...)
To sum up, I would like lyx, when it is inside a \L (English), to switch
automatically to English, unless the user explicitly changes it with F12
(\language hebrew), the cursor will NOT MOVE, and the text will be added
where it was, whether it was English or Hebrew.
When moving across already written text, lyx, when spotting a move between
\L and \R should move visually, i.e., to the end of the foreign text and go
backwards (so the arrow keys move to the right direction), and change its
language as well, again, unless explicitly changed by the user by pressing
F12.
Lyx should then understand about spaces being adjacent visually, not
logically, and fix adjacent spaces between RTL and LTR this way.
Is that not simpler to understand, as far as a user is concerned? I am not
referring to coding problems here. Can that be accomplished?
6. I cannot enter an inline equation to the right of the English word.
This looks like a bug. If you're coming from the english, then I think
that the equation should also be in english (see next comment), and
then what you want to do would work. Can you open a bug for this in
bugzilla (and see next comment)? Meanwhile, if you just select the
entire inset, and switch it's language with F12, you'll get what you
want.
This is bug 3011 in bugzilla.
See the fix I sent separately...
7, 8 seem to be the same issue as in 6...?
Probably. I am not entering them as a separate bug for now.
Are these solved with the above-mentioned fix?
Is it already in svn? if not, where is the patch? I will check.
10. References which get added RTL are backward in output, i.e. instead
of 12, 13, 14, etc. I get 21, 31, 41. Even if I try to switch the
language to English, the reference gets marked RTL. I suspect it will
be the same for figure numbers above 10. For equations it comes out
fine for some reason even above 10.
Is the problem here in the display or in latex or both? I haven't
checked this yet...
This is bug 3005. The output (DVI) comes out reversed. On screen you
don't
see numbers anyway, you see labels. The references are inside the \R{ }
in
latex and that is the problem I guess.
Hmmm... I see that this was like that in 1.3.X, too, so it's not a
regression. Any ideas on how to solve it? There are a few issues for which
I know what needs to be done at the latex level, but I don't really know
latex+hebrew/ivritex well enough in order to understand why exactly...
(e.g., I think bug 3555 is a similar thing, see
Re: [patch] Language of Inset (bug 3011)
Dov Feldstern wrote:
Jean-Marc Lasgouttes wrote:
Dov == Dov Feldstern
[EMAIL PROTECTED] writes:
Dov Hi! attached find a very simple fix for
Dov http://bugzilla.lyx.org/show_bug.cgi?id=3011 (which is a
Dov regression relative to 1.3.X). The problem is that when typing
Dov some LTR in an RTL paragraph (or vice versa), when an inset is
Dov inserted, it gets inserted in the paragraph language, and not in
Dov the current language. It's more correct for the inset to be
Dov inserted in the current language. That's what this patch
Dov achieves.
Is there a reason why you use real_current_font instead of
current_font? The later is the non-expanded version, which is IMO
better.
Attached is the patch using current_font. Is this Okay?
Dov
Index: lyx-devel/src/Text2.cpp
===
--- lyx-devel.orig/src/Text2.cpp2007-06-14 23:46:30.0 +0300
+++ lyx-devel/src/Text2.cpp 2007-06-14 23:48:16.0 +0300
@@ -670,7 +670,7 @@
{
BOOST_ASSERT(this == cur.text());
BOOST_ASSERT(inset);
- cur.paragraph().insertInset(cur.pos(), inset,
+ cur.paragraph().insertInset(cur.pos(), inset, current_font,
Change(cur.buffer().params().trackChanges ?
Change::INSERTED :
Change::UNCHANGED));
}
was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Separating this into different issues, it's getting long... Miki Dovrat wrote: 3. If I have a Hebrew paragraph with an English word like ? English ? ? and I type continuously, the spaces are Hebrew. Now if I try to continue the Hebrew to the right of the English word, but after the Hebrew space, as to continue typing, I can't: If I am in English mode and I press F12 (bound to language hebrew), the cursor jumps to the left of the English word. If I was already in hebrew (if the cursor was resting on a hebrew word before and then I moved it to this position with the mouse), then it's ok. This is correct. If you move to the right of the english through the english, then at the end you are still considered to be in English, at the end of the english; so switching to hebrew should move you to the left of the english. You can do what you want by moving to the beginning of the english, and then move back one more, that'll bring you to the space before the english; then if you move one Left, you'll be after the space, but still in hebrew. Typing in hebrew will then work as you want it to. What you say is correct, and I have found that out, but it is not intuitive and takes learning lyx's behavior. Also, when you just land there with the mouse, you have the same problem. Can you think of a sane way to solve this? What do you want LyX to do: to say that if you've been typing in english and then switch the language to hebrew, that it should jump back to before the english, and continue inserting the hebrew there? 'cause I think that's what would be necessary to do what you want in this case --- but then just plain typing in would be a real pain: you type some hebrew, want to insert a word in english so you switch to english, type the word, then switch back to hebrew (you want to continue typing --- after the english word, of course) and find yourself before the english word! I don't see any way out. And BTW, I'm not sure --- but I don't think that visual mode will solve this, either... I would like lyx to be visual, and I think it will solve this problem, since the cursor will STAY PUT in the location it is in without jumping anywhere. That will work when moving, but not when typing: when you type in hebrew, and then switch to english, and then back to hebrew --- where do you want the hebrew to continue: to the left or to the right of the english? I want it to continue on the left: usually I type in logical order, not first all the hebrew and then go back and insert the english... In latex, you will have \L's and \R's all over the place, and you can clean that up later - maybe when saving, maybe when leaving the row. I don't know enough about what lyx does (I wanted to get into it but I lack the time, maybe in the future...) To sum up, I would like lyx, when it is inside a \L (English), to switch automatically to English I believe it does this... , unless the user explicitly changes it with F12 (\language hebrew), the cursor will NOT MOVE, and the text will be added where it was, whether it was English or Hebrew. Again, this doesn't make sense when typing. It means after every insertion of an english word, you'll have to move the cursor before continuing to type in hebrew...
Re: 20% speedup of paragraph redraw with simple patch
Andre Poenitz wrote: On Thu, Jun 14, 2007 at 05:49:53PM +0200, Abdelrazak Younes wrote: Moreover, it remains to be seen whether the map is faster in the cases where the container typically has at most 10 elements. It might be that a stupid plain loop is faster... Maybe not faster but a lot cleaner. You may have noticed that users are complaining about speed, not on code cleanliness. When you quote something please quote the full sentence: Am I am pretty sure that it will make the cases similar to the one found by Stefan easier to optimize. I end this thread. Abdel.
Re: 20% speedup of paragraph redraw with simple patch
On Thu, Jun 14, 2007 at 09:01:49PM +0200, Andre Poenitz wrote: On Thu, Jun 14, 2007 at 05:05:32PM +0200, Stefan Schimanski wrote: I did some profiling of paragraph drawing. 20% of the whole time while inserting characters and redrawing the screen was taken by Paragraph::getInset calls, each for every character. This is stupid. See the patch below for a loop iterating over the insets of a paragraph instead. O(insetnumber) instead of O(charnumber * ln insetnumber). Stefan ... Good catch. Patch is fine with me. [And I continue hating that wide() business ;-}] Andre' Come and help rip it out from 1.6 in Bromarv... Abdel's idea is sound and perhaps that's what I should have done in the first place rather than this elaborate hack. - Martin
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Miki Dovrat wrote: When moving across already written text, lyx, when spotting a move between \L and \R should move visually, i.e., to the end of the foreign text and go backwards (so the arrow keys move to the right direction), and change its language as well, again, unless explicitly changed by the user by pressing F12. Regarding visual movement, I agree that it would solve some (not all!) of these issues. But I also think that implementing visual movement correctly will require some refactoring of the cursor movement code. I hope to get working on it soon, but even if it is ready before 1.5.0 is released, I'm not sure that those kinds of changes should go in at this point. And in that case, I'd rather focus in the meantime on issues which can, perhaps, be fixed for 1.5.0.
Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Dov Feldstern wrote: , unless the user explicitly changes it with F12 (\language hebrew), the cursor will NOT MOVE, and the text will be added where it was, whether it was English or Hebrew. Again, this doesn't make sense when typing. It means after every insertion of an english word, you'll have to move the cursor before continuing to type in hebrew... No, in Visual mode, when LyX detect an RTL characters the insertion should happen at the right place. IOW, the jumping will happen at _writing_ time not at cursor navigation time like in so-called 'logical mode'. IMHO of course :-) Abdel.
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Miki Dovrat wrote: To sum up, I would like lyx, when it is inside a \L (English), to switch automatically to English, unless the user explicitly changes it with F12 (\language hebrew), the cursor will NOT MOVE, and the text will be added where it was, whether it was English or Hebrew. When moving across already written text, lyx, when spotting a move between \L and \R should move visually, i.e., to the end of the foreign text and go backwards (so the arrow keys move to the right direction), and change its language as well, again, unless explicitly changed by the user by pressing F12. Lyx should then understand about spaces being adjacent visually, not logically, and fix adjacent spaces between RTL and LTR this way. Is that not simpler to understand, as far as a user is concerned? FWIW I 100% agree with you but I am not (yet) an RTL writer :-) I am not referring to coding problems here. Can that be accomplished? I believe it would be simpler to achieve than the current complicated logical navigation. The difficult part would be the automagic insertion at the right place. Abdel.
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Dov Feldstern wrote: Miki Dovrat wrote: When moving across already written text, lyx, when spotting a move between \L and \R should move visually, i.e., to the end of the foreign text and go backwards (so the arrow keys move to the right direction), and change its language as well, again, unless explicitly changed by the user by pressing F12. Regarding visual movement, I agree that it would solve some (not all!) of these issues. But I also think that implementing visual movement correctly will require some refactoring of the cursor movement code. I hope to get working on it soon, but even if it is ready before 1.5.0 is released, I'm not sure that those kinds of changes should go in at this point. And in that case, I'd rather focus in the meantime on issues which can, perhaps, be fixed for 1.5.0. Agreed :-) Abdel.
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Miki Dovrat wrote: 6. I cannot enter an inline equation to the right of the English word. This looks like a bug. If you're coming from the english, then I think that the equation should also be in english (see next comment), and then what you want to do would work. Can you open a bug for this in bugzilla (and see next comment)? Meanwhile, if you just select the entire inset, and switch it's language with F12, you'll get what you want. This is bug 3011 in bugzilla. See the fix I sent separately... 7, 8 seem to be the same issue as in 6...? Probably. I am not entering them as a separate bug for now. Are these solved with the above-mentioned fix? Is it already in svn? if not, where is the patch? I will check. See http://permalink.gmane.org/gmane.editors.lyx.devel/87817. Let's continue the discussion of this issue in response to that thread.
Re: 20% speedup of paragraph redraw with simple patch
Dov == Dov Feldstern [EMAIL PROTECTED] writes: Dov Hmm, I just came across this yesterday when trying to figure out Dov what was going on with bug 3011, and wondered about it. I'm not Dov sure if this is what you mean or not, but it might be relevant... Dov http://www.lyx.org/trac/browser/lyx-devel/trunk/src/Paragraph.cpp?rev=18599#L446 Yes, what I mean is that in this case we would have to recreate the structure instead of update it. I do not know how costly it is but Abdel is confident that it is not a problem. JMarc
Re: [patch] Language of Inset (bug 3011)
Dov == Dov Feldstern [EMAIL PROTECTED] writes: Dov Attached is the patch using current_font. Is this Okay? The patch is definitely correct. Please apply. Dov I actually wanted to solve this in a more complete way, by Dov setting the font to current_font directly within Dov paragraph::insertInset() if no explicit font is provided; but I Dov don't have access to real_current_font within Paragraph... Any Dov thoughts on this? No, Paragraph is not supposed to have access to this font. Dov Could the versions of insertInset which do not take a font be Dov made private, so that one would always have to provide a font Dov explicitly? Yes, I think we should do this (or even check whether these versions are useful at all). JMarc
Spaces in Bidi part #2
Okay, I'm starting a new thread for this issue. This is now bug 3870 in bugzilla (http://bugzilla.lyx.org/show_bug.cgi?id=3870). The problem: typing spaces at RTL/LTR boundaries does not always do what the user expects/wants. (The reason I opened a new bug, is that this really a different issue than what we have solved up until now (bug 3789): that was mainly about getting the GUI and backend to match. Now that they match, we can deal with the real issue. The only thing we have done for the real issue so far, is that in normal typing --- i.e., typing in the logical order --- the language of the space will be set correctly, regardless of whether or not the user switches languages before or after typing the space. We may decide, in the end, that that's not necessary, either...) Note that there are two separate issues: 1) What the end result should look like (at the buffer / latex output level) 2) How we achieve that result, at the same time making the user-experience as simple as possible Note that (1) is totally unrelated to visual/logical movement --- there's no cursor at all in the end result. I'm quite sure that also (2) is orthogonal to the question of visual movement, but I'm not 100% sure... Obviously, (2) can only be solved after (1), because we first need to know what we want to achieve. So I'm focusing on (1) for now: There there are some subtleties to this issue which I'm not sure that everyone appreciates, and which make a solution to this not as trivial as some of you seem to think it should be. The hard part is to make sure that we maintain logical correctness of the resulting text. Logical correctness is important, because if the text is *not* logically correct, then you get hidden problems: usually the text looks fine, so the user thinks there's no problem. Bit in certain situations, problems suddenly appear, but by then the user isn't aware of them and doesn't notice. For example: I've been saying all along that the *correct* way is that spaces at RTL/LTR boundaries be in the language (direction, really) of the paragraph. Any other situation is logically incorrect. Attached is a lyx document demonstrating this. (Now is the time to look at the file, there are explanations about it inside it itself. For those of you who don't have hebrew in latex, I'm attaching the dvi, too). I think this demonstrates the necessity of maintaining logical correctness. So now we have to see how we achieve (2). However, we have the following rule: any magic has to happen in the GUI; i.e., the LyX buffer should already represent a logically correct situation; i.e., when we generate the latex, we should not have to apply any bidi logic at all --- just make what has *already* been marked as RTL, as RTL, and what's LTR as LTR. So now we can discuss how we go about (2). Hope this clarifies the situation... Dov spaces_at_bidi_boundary.dvi Description: TeX dvi file spaces_at_bidi_boundary.lyx Description: application/lyx
Re: [patch] Language of Inset (bug 3011)
Jean-Marc Lasgouttes wrote: Dov == Dov Feldstern [EMAIL PROTECTED] writes: Dov Attached is the patch using current_font. Is this Okay? The patch is definitely correct. Please apply. Thanks, committed. Dov Could the versions of insertInset which do not take a font be Dov made private, so that one would always have to provide a font Dov explicitly? Yes, I think we should do this (or even check whether these versions are useful at all). JMarc In that case, it looks like there's only one other place where the form without a font is still used: Paragraph::checkBiblio(bool track_changes) I'm not familiar with this function at all. However, it is only used in one place, so I think that it should also get a font, and then call insertInset with a font. I don't know which font should be used here, though. Also note that this function (checkBiblio) has a big FIXME at the top anyhow... I'll try to send a patch which does all this...
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Dov Feldstern wrote: Miki Dovrat wrote: Are these solved with the above-mentioned fix? Is it already in svn? if not, where is the patch? I will check. See http://permalink.gmane.org/gmane.editors.lyx.devel/87817. Let's continue the discussion of this issue in response to that thread. Sorry, wrong link. Anyhow, this is committed now (r18781).
Re: [patch] Language of Inset (bug 3011)
Dov == Dov Feldstern [EMAIL PROTECTED] writes: Dov In that case, it looks like there's only one other place where Dov the form without a font is still used: Dov Paragraph::checkBiblio(bool track_changes) Dov I'm not familiar with this function at all. However, it is only Dov used in one place, so I think that it should also get a font, and Dov then call insertInset with a font. I don't know which font should Dov be used here, though. Also note that this function (checkBiblio) Dov has a big FIXME at the top anyhow... OK. I think this should use an explicit font (but it does not need to access current_font. Dov I'll try to send a patch which does all this... This probably can wait for 1.6, since the real bug is fixed. But you can add this to your personal TODO list :) JMarc
Re: [PATCH-updated] Make HTML Export Work
On Friday 15 June 2007 05:39:01 Richard Heck wrote: Now seeking an OK to commit. Richard Richard has gave this some thought and has tested this thoroughly so I am inclined to give this my OK. Any objection? -- José Abílio
Re: [PATCH-updated] Make HTML Export Work
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Richard The patch also includes some associated updates to the Richard documentation. Jean-Marc But not Extended.lyx. Forget this. This patch does not get rid of originaldir. JMarc
Re: [PATCH-updated] Make HTML Export Work
José == José Matos [EMAIL PROTECTED] writes: José On Friday 15 June 2007 05:39:01 Richard Heck wrote: Now seeking an OK to commit. Richard José Richard has gave this some thought and has tested this José thoroughly so I am inclined to give this my OK. Any objection? Since there is no change to the code, the worst that can happen is that HTML export does not work, which was the case already. So I think it is safe. JMarc
Re: [PATCH-updated] Make HTML Export Work
On Fri, Jun 15, 2007 at 12:39:01AM -0400, Richard Heck wrote: This patch is now slightly updated. In place of the two scripts tex4html_copy.py and dir_copy.py, there is now just one, ext_copy.py. Without any optional arguments, this script acts like dir_copy.py did: It copies all files in LyX's temporary directory to a subdirectory of the target directory. But now the script takes two optional arguments: -e: a list of extensions to copy, by default all -t: an extension to add to the name of the generated target directory, by default LyXconv The idea with the default in the latter case is simply to avoid conflicting filenames. But if, like Uwe, you feel like being reckless ;-), you can do define your HTML copier as: python ext_copy.py -e html,css,png -t . $$i $$o and you'll export to /path/to/filename.html/. Note the use of the dot here. This new patch will allow easy handling of other converters, such as hevea (and if anyone knows what kinds of files it generates, let me know, and I'll add the definition to configure.py). You just have to say what kinds of files to copy. Of course, in some cases, you may end up copying more than you really needed to copy, but avoiding this is complicated and, to my mind, not entirely necessary, as this remains an exceptional case. The patch also includes some associated updates to the documentation. This issue has proven to be difficult, so I think that your solution is the less intrusive and workable one. I think that we should support more actively the converters we look for, i.e., provide a -e switch for latex2html and hevea, but this could be done by others who know the kind of output they generate. Now seeking an OK to commit. I think you got enough of them. Only a suggestion: Please name the script html_copy.py as this is what it is intended for. If you think that it can be used for a more general purpose, such that ext_copy.py is more correct, then avoid adding .html to the directory it creates. Thanks for having solved this long standing problem. -- Enrico
Re: [PATCH-updated] Make HTML Export Work
Richard == Richard Heck [EMAIL PROTECTED] writes: Richard This new patch will allow easy handling of other converters, Richard such as hevea (and if anyone knows what kinds of files it Richard generates, let me know, and I'll add the definition to Richard configure.py). The documentaton is here: http://hevea.inria.fr/doc/index.html but I am not sure what you want to know. Richard The patch also includes some associated updates to the Richard documentation. But not Extended.lyx. JMarc
Re: [PATCH-updated] Make HTML Export Work
Richard Heck wrote: This patch is now slightly updated. In place of the two scripts tex4html_copy.py and dir_copy.py, there is now just one, ext_copy.py. I was about to suggest that. Without any optional arguments, this script acts like dir_copy.py did: It copies all files in LyX's temporary directory to a subdirectory of the target directory. But now the script takes two optional arguments: -e: a list of extensions to copy, by default all -t: an extension to add to the name of the generated target directory, by default LyXconv Why -t? The idea with the default in the latter case is simply to avoid conflicting filenames. But if, like Uwe, you feel like being reckless ;-), you can do define your HTML copier as: python ext_copy.py -e html,css,png -t . $$i $$o and you'll export to /path/to/filename.html/. Note the use of the dot here. IMHO in the long term the usual ask-overwrite mechanism should kick in if a file with the same name as the directory already exists. Then no artificial suffix is needed. This new patch will allow easy handling of other converters, such as hevea (and if anyone knows what kinds of files it generates, let me know, and I'll add the definition to configure.py). You just have to say what kinds of files to copy. Of course, in some cases, you may end up copying more than you really needed to copy, but avoiding this is complicated and, to my mind, not entirely necessary, as this remains an exceptional case. Why not assume a common set of extensions for all html converters? I guess they are all alike. Index: lib/scripts/ext_copy.py === --- lib/scripts/ext_copy.py(revision 0) +++ lib/scripts/ext_copy.py(revision 0) @@ -0,0 +1,86 @@ +#! /usr/bin/env python +# -*- coding: iso-8859-1 -*- + +# file tex_copy.py Copy/Paste. In general I would not have expected that you can solve this problem without touching the converter machinery. In the long term I think it should be made aware of directories nevertheless. Georg
Re: [PATCH] Strip unused originaldir flag from Converters.{cpp,h}
Jean-Marc Lasgouttes wrote: Richard == Richard Heck [EMAIL PROTECTED] writes: Richard This time with the patch... Richard As said. This flag was removed from configure.py a while ago. Richard It was only ever used with HTML export, and it didn't work Richard there, anyway. I didn't remove it from Converters.* at that Richard time, because I was intending to make more extensive changes Richard to this file in connection with HTML export. But it turned Richard out I didn't need to do that, so all that needs doing now is Richard this little bit of cleanup. Extended.lyx has a reference to it related to literate programming. Are you sure it is not relevant anymore? The problem is that it is horribly broken currently, and fixing it would be a lot of work (see old discussions). I guess that writing a copier for literate programming files would be easier than fixing originaldir, so I think removing the flag is the right thing to do. Georg
Re: [PATCH] Bug 3860 Toc crash when loading a child documents
Abdelrazak Younes wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=3860
SVN Log:
Polish the Toc and labels updating when loading a child document. Fix
Bug 3860: Toc crash when loading a child documents.
* BufferView::loadLyXFile(): simplify, transfer last part to
LyXView::loadLyXFile()
* LyXView:
- setBuffer(): properly update the labels and the Toc if this is [LOAD
Child Document] command.
- loadLyXFile(): get some code from BufferView::loadLyXFile() and from
LyXFunc::LFUN_BUFFER_CHILD, properly handle the child document case.
* LyXFunc: simplify LFUN_BUFFER_CHILD.
* LyX: adapt to loadLyXFile() API change.
With this in place, the only thing missing for proper multipart document
support is to automatically update the parent Buffer when switching from
the parent Buffer. This would be very useful when you work with multiple
document sharing the same child documents (as I often do).
Seeking two OKs. As this is a critical bug fixing patch I reckon this
should go before RC2. Once this is in, I'll look at the automatic
updating of LOF, LOT and LOL... LOL!
I won't be able to commit it this week-end so could anyone show a little
bit of interest please?
Patch updated to latest svn attached...
Abdel.
Index: Buffer.cpp
===
--- Buffer.cpp (revision 18780)
+++ Buffer.cpp (working copy)
@@ -1613,7 +1613,11 @@
void Buffer::setParentName(string const name)
{
- params().parentname = name;
+ if (name == pimpl_-filename.absFilename())
+ // Avoids recursive include.
+ params().parentname.clear();
+ else
+ params().parentname = name;
}
Index: BufferView.cpp
===
--- BufferView.cpp (revision 18780)
+++ BufferView.cpp (working copy)
@@ -233,8 +233,8 @@
graphics::Previews::get().generateBufferPreviews(*buffer_);
}
-
-bool BufferView::loadLyXFile(FileName const filename, bool tolastfiles)
+// FIXME: all of this should go in a helper file in buffer_func.
+bool BufferView::loadLyXFile(FileName const filename)
{
// File already open?
if (theBufferList().exists(filename.absFilename())) {
@@ -280,27 +280,7 @@
}
setBuffer(b);
- // Send the errors signal in case of parsing errors
- b-errors(Parse);
- // Update the labels and section numbering.
- updateLabels(*buffer_);
- // scroll to the position when the file was last closed
- if (lyxrc.use_lastfilepos) {
- pit_type pit;
- pos_type pos;
- boost::tie(pit, pos) =
LyX::ref().session().lastFilePos().load(filename);
- // if successfully move to pit (returned par_id is not zero),
update metrics and reset font
- if (moveToPosition(pit, pos, 0, 0).get1()) {
- if (fitCursor())
- updateMetrics(false);
- buffer_-text().setCurrentFont(cursor_);
- }
- }
-
- if (tolastfiles)
- LyX::ref().session().lastFiles().add(FileName(b-fileName()));
-
return true;
}
Index: BufferView.h
===
--- BufferView.h(revision 18780)
+++ BufferView.h(working copy)
@@ -94,7 +94,7 @@
void resize();
/// load a buffer into the view.
- bool loadLyXFile(support::FileName const name, bool tolastfiles =
true);
+ bool loadLyXFile(support::FileName const name);
/// perform pending metrics updates.
/** \c Update::FitCursor means first to do a FitCursor, and to
Index: frontends/LyXView.cpp
===
--- frontends/LyXView.cpp (revision 18780)
+++ frontends/LyXView.cpp (working copy)
@@ -20,6 +20,7 @@
#include Gui.h
#include Buffer.h
+#include buffer_funcs.h
#include BufferList.h
#include BufferParams.h
#include BufferView.h
@@ -31,6 +32,7 @@
#include gettext.h
#include Intl.h
#include callback.h
+#include LyX.h
#include LyXFunc.h
#include LyXRC.h
#include Text.h
@@ -122,27 +124,44 @@
}
-void LyXView::setBuffer(Buffer * b)
+void LyXView::setBuffer(Buffer * b, bool child_document)
{
busy(true);
BOOST_ASSERT(work_area_);
- if (work_area_-bufferView().buffer())
+ Buffer * oldBuffer = work_area_-bufferView().buffer();
+ // parentfilename will be used in case when we switch to a child
+ // document (hence when child_document is true)
+ string parentfilename;
+ if (oldBuffer) {
+ parentfilename = oldBuffer-fileName();
disconnectBuffer();
+ }
if (!b theBufferList().empty())
getDialogs().hideBufferDependent();
work_area_-bufferView().setBuffer(b);
- // Make sure the TOC is updated
Re: Sample test files and improved patch Re: [patch] Enable tex2lyx read back lyx exported .tex as much as possible
hzluo wrote: Please test and give me feedback. Thanks! I have a couple of comments you might want to consider or ignore: 1) Jose plans to rewrite tex2lyx in python, so be aware that all your work is wasted if he ever does that. The threat of the python rewrite is the only reason why I did not convert tex2lyx to the unicode file format already many months ago. 2) As I wrote in bugzilla you are creating an invalid .lyx file, because you mix formats (caption stuff). This has been done in relyx (the predecessor of tex2lyx) and caused lots of trouble. Ignoring esint is also something that should only be done if tex2lyx writes a file format after the esint introduction (i.e. 253). 3) If there is a choice to be made between correct output and small amount of ERT then tex2lyx currently opts for correct output. This is important if you convert large documents and don't want to go manually through everything and check it. If you implement conversions that are not 100% correct, but will only produce similar output (like you did with the centerline stuff), then please add a command line option that enables you to choose between correct output with much ERT or slightly modified output with little ERT. 4) You combined several independent things in one patch. It is better to tackle each problem separately. That will make it easier to fix potential bugs that might arise from one of the changes, because you can then revert only one feature. 5) The preamble marking in Buffer.cpp and BufferParams.cpp is a hack. See http://www.lyx.org/trac/browser/lyx-devel/branches/personal/baum/playground/src/tex2lyx/preamble.C for a solution that does also work with stuff produced by older versions of LyX. 6) known_font_shapes and known_coded_font_shapes must match, they have different sizes with your patch. 7) eat_whitespace() and p.skip_spaces() are not equivalent (read the doc of both). If you exchange one by the other then please first show what goes wrong without the change and demonstrate that it still parses all kinds of weird white spaces correctly (comments, newlines etc) correctly. Almost always eat_whitespace() is what you want. This might all sound very negative, please don't get that wrong. It is good that somebody works on tex2lyx (and it would even be better if the python phantom would be killed). But since TeX is a monster of a programming language and has many surprising features it is very easy to get something wrong. It is easy to get the first 80% correct, the remaining bits become more and more difficult. Since tex2lyx is already pretty good you have unfortunately no choice but to work on the difficult parts ;-( Georg
Re: Sample test files and improved patch Re: [patch] Enable tex2lyx read back lyx exported .tex as much as possible
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg 1) Jose plans to rewrite tex2lyx in python, so be aware that Georg all your work is wasted if he ever does that. The threat of the Georg python rewrite is the only reason why I did not convert tex2lyx Georg to the unicode file format already many months ago. And I think Jose' is being a big pain with his threat. It is a pity to see tex2lyx stalled, especially since it is not clear why the python version would be so much better. JMarc
Re: 2007 LyX Meeting: Invitation
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin INVITATION Martin Hereby I invite everyone interested to participate in the ?th Martin International LyX Developers' Meeting in Bromarv, Western Martin Uusimaa, municipality of Ekenäs. What is the status? Who is coming and when? There are some convenient Air France Flights, but I need to know more about when to come. Also, is 1 hour enough to go to city center and catch the bus? JMarc
Re: Sample test files and improved patch Re: [patch] Enable tex2lyx read back lyx exported .tex as much as possible
Georg Baum wrote: This might all sound very negative, please don't get that wrong. It is good that somebody works on tex2lyx +1 (and it would even be better if the python phantom would be killed). A phantom cannot be killed, it is not alive ;-) FYI Hangzai I have written somewhere in my TODO list that tex2lyx should be integrated into LyX. This would ease the maintenance as we won't have to care about the LyX file format compatibility (because we would fill in the Buffer structure directly and let LyX care about writing a proper LyX file). Abdel.
Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
I was going to say, let the cursor always stay where it is, and the user will learn to press END (end of line) to move it to continue typing. It is logical, (not in the logical direction sense), expected and easily adapted to by the user, as there are no surprises there. Abdel's idea is even better. I second it. When writing, lyx will assume you want to jump to the end of line, but when editing, it will assume you don't!! Miki Abdelrazak Younes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Dov Feldstern wrote: , unless the user explicitly changes it with F12 (\language hebrew), the cursor will NOT MOVE, and the text will be added where it was, whether it was English or Hebrew. Again, this doesn't make sense when typing. It means after every insertion of an english word, you'll have to move the cursor before continuing to type in hebrew... No, in Visual mode, when LyX detect an RTL characters the insertion should happen at the right place. IOW, the jumping will happen at _writing_ time not at cursor navigation time like in so-called 'logical mode'. IMHO of course :-) Abdel.
Re: Sample test files and improved patch Re: [patch] Enable tex2lyx read back lyx exported .tex as much as possible
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak FYI Hangzai I have written somewhere in my TODO list that Abdelrazak tex2lyx should be integrated into LyX. This would ease the Abdelrazak maintenance as we won't have to care about the LyX file Abdelrazak format compatibility (because we would fill in the Buffer Abdelrazak structure directly and let LyX care about writing a proper Abdelrazak LyX file). I would like that much better than the python thing. JMarc
Re: Sample test files and improved patch Re: [patch] Enable tex2lyx read back lyx exported .tex as much as possible
Abdelrazak Younes wrote: Georg Baum wrote: (and it would even be better if the python phantom would be killed). A phantom cannot be killed, it is not alive ;-) Well, it is alive enough to have real world effects. FYI Hangzai I have written somewhere in my TODO list that tex2lyx should be integrated into LyX. This would ease the maintenance as we won't have to care about the LyX file format compatibility (because we would fill in the Buffer structure directly and let LyX care about writing a proper LyX file). The integration might have advantages (e.g. inplace tex2lyx for clipboard snippets), but file format changes will only play a marginal role. The reason why it is some work to update tex2lyx to the newest file format does not lie in syntactical changes, e.g. \layout-\begin_layout. These were always done very quickly. The difficult thing is to support added functionality: When I adapted tex2lyx from the minipage to the box inset it was easy to simply change the output from the old minipage case. The difficult thing is to parse the other boxes correctly (ovalbox etc). This is still not done. Or in the unicode case: You have to translate the TeX stuff to unicode. This is difficult with all the encoding switching that may happen. Spitting out the result in utf8 is as easy as filling a paragraph container. Georg
Re: Sample test files and improved patch Re: [patch] Enable tex2lyx read back lyx exported .tex as much as possible
Abdelrazak Younes wrote: Georg Baum wrote: The integration might have advantages (e.g. inplace tex2lyx for clipboard snippets), but file format changes will only play a marginal role. The reason why it is some work to update tex2lyx to the newest file format does not lie in syntactical changes, e.g. \layout-\begin_layout. These were always done very quickly. Because you know how to do it quickly and you know the LyX file format. Most developpers don't know the file format so the other advantage of integrating tex2lyx is that it's easier for us to help. Try it, it is really not difficult. Just look at the corresponding lyx2lyx functions (in fact I also did that to make sure to catch corner cases). The difficult thing is to support added functionality: When I adapted tex2lyx from the minipage to the box inset it was easy to simply change the output from the old minipage case. The difficult thing is to parse the other boxes correctly (ovalbox etc). This is still not done. Yes but the parsing difficulty is independant of the integration, isn't it? I mean it will have to be done, integration or not. Sure. I am not saying that integration is bad, but IMHO the improvements WRT file format changes are only marginal, and if that would be the only benefit it would probably not justify the integration effort. Georg
Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Miki Dovrat wrote: I was going to say, let the cursor always stay where it is, and the user will learn to press END (end of line) to move it to continue typing. It is logical, (not in the logical direction sense), expected and easily adapted to by the user, as there are no surprises there. It doesn't seem logical at all to me, though I guess I user could get used to it. But I'm glad you've dropped this idea... ;) Abdel's idea is even better. I second it. When writing, lyx will assume you want to jump to the end of line, but when editing, it will assume you don't!! How does one differentiate between writing and editing? By whether I'm at the end of a paragraph or not? This is what (I think) I said somewhere in this thread: in order to get the behavior to be more intuitive, you have to start using heuristics which try to figure out what did the user mean this time?. And the nature of heuristics is that they are sometimes right, sometimes wrong; and they certainly make the code more complicated. So yes, it's a possibility, but we should consider carefully if the heuristics are correct, and whether we want to implement them in each case... Miki Abdelrazak Younes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Dov Feldstern wrote: , unless the user explicitly changes it with F12 (\language hebrew), the cursor will NOT MOVE, and the text will be added where it was, whether it was English or Hebrew. Again, this doesn't make sense when typing. It means after every insertion of an english word, you'll have to move the cursor before continuing to type in hebrew... No, in Visual mode, when LyX detect an RTL characters the insertion should happen at the right place. IOW, the jumping will happen at _writing_ time not at cursor navigation time like in so-called 'logical mode'. IMHO of course :-) Abdel.
Re: Sample test files and improved patch Re: [patch] Enable tex2lyx read back lyx exported .tex as much as possible
Georg Baum wrote: Abdelrazak Younes wrote: Georg Baum wrote: (and it would even be better if the python phantom would be killed). A phantom cannot be killed, it is not alive ;-) Well, it is alive enough to have real world effects. FYI Hangzai I have written somewhere in my TODO list that tex2lyx should be integrated into LyX. This would ease the maintenance as we won't have to care about the LyX file format compatibility (because we would fill in the Buffer structure directly and let LyX care about writing a proper LyX file). The integration might have advantages (e.g. inplace tex2lyx for clipboard snippets), but file format changes will only play a marginal role. The reason why it is some work to update tex2lyx to the newest file format does not lie in syntactical changes, e.g. \layout-\begin_layout. These were always done very quickly. Because you know how to do it quickly and you know the LyX file format. Most developpers don't know the file format so the other advantage of integrating tex2lyx is that it's easier for us to help. The difficult thing is to support added functionality: When I adapted tex2lyx from the minipage to the box inset it was easy to simply change the output from the old minipage case. The difficult thing is to parse the other boxes correctly (ovalbox etc). This is still not done. Yes but the parsing difficulty is independant of the integration, isn't it? I mean it will have to be done, integration or not. Abdel. Or in the unicode case: You have to translate the TeX stuff to unicode. This is difficult with all the encoding switching that may happen. Spitting out the result in utf8 is as easy as filling a paragraph container. Georg
Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Dov Feldstern wrote: Miki Dovrat wrote: I was going to say, let the cursor always stay where it is, and the user will learn to press END (end of line) to move it to continue typing. It is logical, (not in the logical direction sense), expected and easily adapted to by the user, as there are no surprises there. It doesn't seem logical at all to me, though I guess I user could get used to it. But I'm glad you've dropped this idea... ;) Abdel's idea is even better. I second it. When writing, lyx will assume you want to jump to the end of line, but when editing, it will assume you don't!! How does one differentiate between writing and editing? By whether I'm at the end of a paragraph or not? This is what (I think) I said somewhere in this thread: in order to get the behavior to be more intuitive, you have to start using heuristics which try to figure out what did the user mean this time?. And the nature of heuristics is that they are sometimes right, sometimes wrong; and they certainly make the code more complicated. So yes, it's a possibility, but we should consider carefully if the heuristics are correct, and whether we want to implement them in each case... Also, heuristics make the application behave differently in different situations (that's there purpose!) --- which means that the application is less predictable unless the user exactly understands how the heuristic works... Therefore, I would try to stay away from heuristics if possible, unless they are absolutely intuitive (and the heuristic that I provided above, I think, is not so intuitive). And, the fact is, I think that in this specific case, LyX's behavior is perfectly logical and intuitive, and almost always what I want it to be. If you think otherwise, please explain again exactly what the specific situation is, how you got to that situation, and what you think LyX *should* do in that case...
Re: [PATCH] Strip unused originaldir flag from Converters.{cpp,h}
Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Richard As said. This flag was removed from configure.py a while ago.
Richard It was only ever used with HTML export, and it didn't work
Richard there, anyway. I didn't remove it from Converters.* at that
Richard time, because I was intending to make more extensive changes
Richard to this file in connection with HTML export. But it turned
Richard out I didn't need to do that, so all that needs doing now is
Richard this little bit of cleanup.
Extended.lyx has a reference to it related to literate programming.
Are you sure it is not relevant anymore?
The problem is that it is horribly broken currently, and fixing it would be
a lot of work (see old discussions). I guess that writing a copier for
literate programming files would be easier than fixing originaldir, so I
think removing the flag is the right thing to do.
Yes, I think Georg and I talked about this a while ago, when I was
pursuing HTML export a quite different way. We agreed that this was
broken. In fact, it could lead to data loss, especially if you combined
originaldir with other flags. I got bit by this once.
Regarding the Extended Features manual, I've removed the originaldir
reference. I've also added a cross-reference to the now more extensive
discussion of converters in the Customization manual.
As for the copier, we can just use ext_copy.py in stupidity mode, i.e.,
so it copies everything. I've added that to configure.py. Too much gets
copied, but at least nothing is lost. I've added some comments about
this to the documentation, as well as a comment of the form: If you know
what extensions get generated, here is what you can do.
So, shall I commit? The now current patch is attached. Note that the bit
about configure.py is not yet included in the patch, as I've got other
stuff going on there at the moment.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: src/Converter.cpp
===
--- src/Converter.cpp (revision 18775)
+++ src/Converter.cpp (working copy)
@@ -118,7 +118,7 @@
string const c, string const l)
: from(f), to(t), command(c), flags(l),
From(0), To(0), latex(false), xml(false),
- original_dir(false), need_aux(false)
+ need_aux(false)
{}
@@ -133,8 +133,6 @@
latex = true;
else if (flag_name == xml)
xml = true;
- else if (flag_name == originaldir)
- original_dir = true;
else if (flag_name == needaux)
need_aux = true;
else if (flag_name == resultdir)
@@ -399,12 +397,10 @@
}
// FIXME UNICODE
- string const infile2 = (conv.original_dir)
-? infile.absFilename() : to_utf8(makeRelPath(from_utf8(infile.absFilename()),
- from_utf8(path)));
- string const outfile2 = (conv.original_dir)
-? outfile.absFilename() : to_utf8(makeRelPath(from_utf8(outfile.absFilename()),
- from_utf8(path)));
+ string const infile2 =
+to_utf8(makeRelPath(from_utf8(infile.absFilename()), from_utf8(path)));
+ string const outfile2 =
+to_utf8(makeRelPath(from_utf8(outfile.absFilename()), from_utf8(path)));
string command = conv.command;
command = subst(command, token_from, quoteName(infile2));
@@ -427,19 +423,19 @@
buffer-message(_(Executing command: )
+ from_utf8(command));
- Systemcall::Starttype const type = (dummy)
-? Systemcall::DontWait : Systemcall::Wait;
Systemcall one;
int res;
- if (conv.original_dir) {
-FileName path(buffer-filePath());
-support::Path p(path);
-res = one.startscript(type,
+ if (dummy) {
+res = one.startscript(Systemcall::DontWait,
to_filesystem8bit(from_utf8(command)));
- } else
-res = one.startscript(type,
- to_filesystem8bit(from_utf8(command)));
+// We're not waiting for the result, so we can't do anything
+// else here.
+return true;
+ }
+ res = one.startscript(Systemcall::Wait,
+to_filesystem8bit(from_utf8(command)));
+
if (!real_outfile.empty()) {
Mover const mover = getMover(conv.to);
if (!mover.rename(outfile, real_outfile))
Index: src/Converter.h
===
--- src/Converter.h (revision 18775)
+++ src/Converter.h (working copy)
@@ -55,8 +55,6 @@
bool latex;
/// The converter is xml
bool xml;
- /// Do we need to run the converter in the original directory?
- bool original_dir;
/// This converter needs the .aux files
bool need_aux;
/// If the converter put the result in a directory, then result_dir
Index: lib/doc/Extended.lyx
Re: [PATCH-updated] Make HTML Export Work
Georg Baum wrote: Richard Heck wrote: Without any optional arguments, this script acts like dir_copy.py did: It copies all files in LyX's temporary directory to a subdirectory of the target directory. But now the script takes two optional arguments: -e: a list of extensions to copy, by default all -t: an extension to add to the name of the generated target directory, by default LyXconv Why -t? Well, -e would be better, but it was taken. 't' was for target. I didn't have any better ideas. The idea with the default in the latter case is simply to avoid conflicting filenames. But if, like Uwe, you feel like being reckless ;-), you can do define your HTML copier as: python ext_copy.py -e html,css,png -t . $$i $$o and you'll export to /path/to/filename.html/. Note the use of the dot here. IMHO in the long term the usual ask-overwrite mechanism should kick in if a file with the same name as the directory already exists. Then no artificial suffix is needed. Yes. But copiers don't know about that at present, and it's not clear how they could. This new patch will allow easy handling of other converters, such as hevea (and if anyone knows what kinds of files it generates, let me know, and I'll add the definition to configure.py). You just have to say what kinds of files to copy. Of course, in some cases, you may end up copying more than you really needed to copy, but avoiding this is complicated and, to my mind, not entirely necessary, as this remains an exceptional case. Why not assume a common set of extensions for all html converters? I guess they are all alike. I don't know whether that is true or not. I've checked tex4ht and latex2html, and they both seem to generate only .html, .css, and .png. But especially with image formats, it's hard to know what you might find. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH-updated] Make HTML Export Work
Enrico Forestieri wrote: On Fri, Jun 15, 2007 at 12:39:01AM -0400, Richard Heck wrote: This issue has proven to be difficult, so I think that your solution is the less intrusive and workable one. I think that we should support more actively the converters we look for, i.e., provide a -e switch for latex2html and hevea, but this could be done by others who know the kind of output they generate. I've added it for latex2html. I'm less sure about hevea. Now seeking an OK to commit. I think you got enough of them. Only a suggestion: Please name the script html_copy.py as this is what it is intended for. If you think that it can be used for a more general purpose, such that ext_copy.py is more correct, then avoid adding .html to the directory it creates. The html part is actually added independently: It's taken from the output filename that is passed to the script. It should be more generally useful. It can be used any time multiple files are generated, and it seems that Noweb conversion is another place it can be used. Who knew? rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH-updated] Make HTML Export Work
Richard Heck wrote: Georg Baum wrote: Richard Heck wrote: Without any optional arguments, this script acts like dir_copy.py did: It copies all files in LyX's temporary directory to a subdirectory of the target directory. But now the script takes two optional arguments: -e: a list of extensions to copy, by default all -t: an extension to add to the name of the generated target directory, by default LyXconv Why -t? Well, -e would be better, but it was taken. 't' was for target. I didn't have any better ideas. With target I associate the complete name. What about -s for suffix? IMHO in the long term the usual ask-overwrite mechanism should kick in if a file with the same name as the directory already exists. Then no artificial suffix is needed. Yes. But copiers don't know about that at present, and it's not clear how they could. They don't need to. AFAIK LyX does this check that before calling a copier. In fact I don't know what happens if the existing object is a file, and a directory is to be created, or vice versa. I guess that the operation will fail with some weird error if the users chooses to overwrite. Why not assume a common set of extensions for all html converters? I guess they are all alike. I don't know whether that is true or not. I've checked tex4ht and latex2html, and they both seem to generate only .html, .css, and .png. But especially with image formats, it's hard to know what you might find. Users may file a bug report if something is missing :-) Georg
Re: [PATCH-updated] Make HTML Export Work
Georg Baum wrote: Richard Heck wrote: Georg Baum wrote: Richard Heck wrote: Without any optional arguments, this script acts like dir_copy.py did: It copies all files in LyX's temporary directory to a subdirectory of the target directory. But now the script takes two optional arguments: -e: a list of extensions to copy, by default all -t: an extension to add to the name of the generated target directory, by default LyXconv Why -t? Well, -e would be better, but it was taken. 't' was for target. I didn't have any better ideas. With target I associate the complete name. What about -s for suffix? As you'll see, I've committed. But I'll change this. That is better. IMHO in the long term the usual ask-overwrite mechanism should kick in if a file with the same name as the directory already exists. Then no artificial suffix is needed. Yes. But copiers don't know about that at present, and it's not clear how they could. They don't need to. AFAIK LyX does this check that before calling a copier. In fact I don't know what happens if the existing object is a file, and a directory is to be created, or vice versa. I guess that the operation will fail with some weird error if the users chooses to overwrite. I'll have a look at this. I plan to have a look at bug 3047 anyway. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3860 Toc crash when loading a child documents
Abdelrazak Younes wrote: I won't be able to commit it this week-end so could anyone show a little bit of interest please? I've patched and am compiling now. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3860 Toc crash when loading a child documents
On Friday 15 June 2007 18:57:44 Richard Heck wrote: I've patched and am compiling now. rh If it fixes the crash you have my OK. :-) -- José Abílio
Re: [PATCH] Bug 3860 Toc crash when loading a child documents
Abdelrazak Younes wrote: I won't be able to commit it this week-end so could anyone show a little bit of interest please? I've patched and am compiling now. Me too. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] Space displayed after macro, #3705
On Friday 15 June 2007 19:01:23 Stefan Schimanski wrote: Is it ok, José? It's only about cosmetics... Stefan OK. -- José Abílio
RC2 coming soon
Hi all, I will start looking to remaining issues before RC2, AFAIR there are two patches that I would like to have before the release, one by Jürgen that has a file format change and another related with reverting documents to 1.4. Is there anything else that I am missing before RC2? Regards, PS: The plan is to release RC2 in a couple of days as soon as the remaining patches are committed, and this should happen before Tuesday night. -- José Abílio
Re: [patch] Space displayed after macro, #3705
Is it ok, José? It's only about cosmetics...
Stefan
Am 15.06.2007 um 08:39 schrieb Stefan Schimanski:
Here is a patch for http://bugzilla.lyx.org/show_bug.cgi?id=3705.
It adds the kerning method to a macro to inherit the kerning from
the expanded form. Moreover the marker metrics calls are remove as
they are not drawn anyway.
Stefan
Index: src/mathed/MathMacro.h
===
--- src/mathed/MathMacro.h (Revision 18774)
+++ src/mathed/MathMacro.h (Arbeitskopie)
@@ -54,6 +54,8 @@
///
docstring name() const;
///
+ int kerning() const { return kerning_; }
+ ///
void setExpansion(MathData const exp, MathData const args)
const;
///
@@ -85,6 +87,8 @@
mutable MacroData macroBackup_;
///
mutable bool editing_;
+ ///
+ mutable int kerning_;
};
Index: src/mathed/MathMacro.cpp
===
--- src/mathed/MathMacro.cpp(Revision 18774)
+++ src/mathed/MathMacro.cpp(Arbeitskopie)
@@ -44,6 +44,8 @@
bool metrics(MetricsInfo mi, Dimension dim) const;
///
void draw(PainterInfo , int x, int y) const;
+ ///
+ int kerning() const { return mathMacro_.cell(idx_).kerning(); }
private:
std::auto_ptrInset doClone() const;
@@ -65,7 +67,6 @@
macro.unlock();
mathMacro_.cell(idx_).metrics(mi, dim);
macro.lock();
- metricsMarkers2(dim);
if (dim_ == dim)
return false;
dim_ = dim;
@@ -114,6 +115,7 @@
bool MathMacro::metrics(MetricsInfo mi, Dimension dim) const
{
+ kerning_ = 0;
if (!MacroTable::globalMacros().has(name())) {
mathed_string_dim(mi.base.font, Unknown: + name(), dim);
} else {
@@ -143,10 +145,10 @@
macro.lock();
expanded_.metrics(mi, dim);
macro.unlock();
+ kerning_ = expanded_.kerning();
editing_ = false;
}
}
- metricsMarkers2(dim);
if (dim_ == dim)
return false;
dim_ = dim;
@@ -199,7 +201,6 @@
if (editing_ != editing(pi.base.bv) || macroBackup_ != macro)
pi.base.bv-cursor().updateFlags(Update::Force);
}
- drawMarkers2(pi, x, y);
}
macrospacearound.patch
PGP.sig
Description: Signierter Teil der Nachricht
Re: [PATCH] Bug 3860 Toc crash when loading a child documents
Tried it a bit with child documents. Looks fine. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: RC2 coming soon
José Matos wrote: Hi all, I will start looking to remaining issues before RC2, AFAIR there are two patches that I would like to have before the release, one by Jürgen that has a file format change and another related with reverting documents to 1.4. I think it'd be nice to have Abdel's child docs TOC patch by then. I'm working on it now. There are still some issues. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Richard Heck wrote: Abdelrazak Younes wrote: I won't be able to commit it this week-end so could anyone show a little bit of interest please? I've patched and am compiling now. This patch does fix that crash, but I'm seeing some other odd behavior, and I'm getting another crash. I don't know to what extent those are related to this. I've got a master document with several included child documents. If I open the master document and scroll down in it a ways, then at some point the child documents open due to calls to InsetInclude::fillWithBibKeys(). Or you can make this happen by generating DVI. Anyway, when they do get opened this way, the TOC does not recognize them, and nothing I can do makes it do so. That is: The TOC of the main document doesn't show them, and they don't even have their own TOCs. Second problem: Now, with the TOC open, close the master document. BOOM. Backtrace below. I'm guessing that the problem here is related to the first problem. This bug may have been revealed by my don't close buffer dependent dialogs patch: http://www.lyx.org/trac/changeset/18651 I don't think the patch is responsible. Diagnosis: When child docs are automatically opened, LyXView::loadLyXFile() is not called. Rather, loadLyXFile() in buffer_funcs.cpp is called directly from InsetInclude::loadIfNeeded(). As a result, none of the stuff Abdel just added to LyXView.cpp to handle the case where a child doc is MANUALLY loaded deals with the case where one is AUTOMATICALLY loaded. Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is called from LyXView::loadLyXFile(), anyway, all the child doc stuff could be moved there. But I don't know this code terribly well. Abdel? More to come if I can figure this out later. Right now, it's off to the grocery store Richard gdb /home/rgheck/dev/bin/lyx --interpreter=mi2 -quiet font color=blue(gdb) bt/font bt #0 0x00f17402 in __kernel_vsyscall () at /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/stl_tree.h:169 #1 0x0023dd40 in raise () at /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/stl_tree.h:169 #2 0x0023f591 in abort () at /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/stl_tree.h:169 #3 0x006128a5 in __gnu_debug::_Error_formatter::_M_error () at /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/stl_tree.h:169 #4 0x0890406a in lyx::frontend::ControlToc::canOutline (this=0xaa4b9e0, type=0) at /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/debug/vector:199 #5 0x0885e8d4 in lyx::frontend::QToc::canOutline (this=0xaa4b9d8, type=6) at QToc.cpp:47 #6 0x08859a9f in lyx::frontend::TocWidget::enableControls (this=0xa3eaa90, enable=false) at TocWidget.cpp:220 #7 0x0885a6af in lyx::frontend::TocWidget::updateGui (this=0xa3eaa90) at TocWidget.cpp:244 #8 0x0885ac95 in lyx::frontend::TocWidget::qt_metacall (this=0xa3eaa90, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbf884b14) at TocWidget_moc.cpp:84 #9 0x008a782f in QMetaObject::activate () at /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/stl_tree.h:169 #10 0x008a801a in QMetaObject::activate () at /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/stl_tree.h:169 #11 0x0885e7dd in lyx::frontend::QToc::modelReset (this=0xaa4b9d8) at QToc_moc.cpp:76 #12 0x0885f551 in lyx::frontend::QToc::initialiseParams (this=0xaa4b9d8, [EMAIL PROTECTED]) at QToc.cpp:119 #13 0x0869b04d in lyx::Dialogs::updateBufferDependent (this=0x9e2e4c0, switched=true) at Dialogs.cpp:222 #14 0x086a69df in lyx::LyXView::setBuffer (this=0x9e2dd44, b=0x0, child_document=false) at LyXView.cpp:164 #15 0x086aa7b4 in boost::detail::function::void_function_obj_invoker0boost::_bi::bind_tvoid, boost::_mfi::mf2void, lyx::LyXView, lyx::Buffer*, bool, boost::_bi::list3boost::_bi::valuelyx::LyXView*, boost::_bi::valuelyx::Buffer*, boost::_bi::valuebool , void::invoke ([EMAIL PROTECTED]) at ../../boost/boost/bind/mem_fn_template.hpp:274 #16 0x080b1cc3 in boost::function0void, std::allocatorvoid ::operator() (this=0xa1d6554) at ../../boost/boost/function/function_template.hpp:692 #17 0x080cc4a4 in boost::signal0void, boost::last_valuevoid, int, std::lessint, boost::functionvoid ()(), std::allocatorvoid ::operator() (this=0xa10cca0) at ../boost/boost/signals/signal_template.hpp:119 #18 0x0809e4ef in ~Buffer (this=0xa10cba0) at Buffer.cpp:230 #19 0x080f1279 in lyx::BufferList::release (this=0x9d2b764, buf=0xa10cba0) at BufferList.cpp:177 #20 0x080f1346 in lyx::BufferList::close (this=0x9d2b764, buf=0xa10cba0, ask=true) at BufferList.cpp:206 #21 0x0831220a in lyx::LyXFunc::closeBuffer (this=0x9d2b730) at LyXFunc.cpp:2073 #22 0x0830618c in lyx::LyXFunc::dispatch (this=0x9d2b730, [EMAIL PROTECTED]) at LyXFunc.cpp:881 #23 0x08311da4 in lyx::LyXFunc::processKeySym (this=0x9d2b730, [EMAIL PROTECTED], state=lyx::key_modifier::ctrl)
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Richard Heck wrote: Richard Heck wrote: Second problem: Now, with the TOC open, close the master document. BOOM. Backtrace below. I'm guessing that the problem here is related to the first problem. This bug may have been revealed by my don't close buffer dependent dialogs patch: http://www.lyx.org/trac/changeset/18651 I don't think the patch is responsible. And oh yeah: You don't get this crash if you load the child docs manually. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Dov Feldstern wrote: Dov Feldstern wrote: Miki Dovrat wrote: I was going to say, let the cursor always stay where it is, and the user will learn to press END (end of line) to move it to continue typing. It is logical, (not in the logical direction sense), expected and easily adapted to by the user, as there are no surprises there. It doesn't seem logical at all to me, though I guess I user could get used to it. But I'm glad you've dropped this idea... ;) Abdel's idea is even better. I second it. When writing, lyx will assume you want to jump to the end of line, but when editing, it will assume you don't!! How does one differentiate between writing and editing? By whether I'm at the end of a paragraph or not? This is what (I think) I said somewhere in this thread: in order to get the behavior to be more intuitive, you have to start using heuristics which try to figure out what did the user mean this time?. And the nature of heuristics is that they are sometimes right, sometimes wrong; and they certainly make the code more complicated. So yes, it's a possibility, but we should consider carefully if the heuristics are correct, and whether we want to implement them in each case... Also, heuristics make the application behave differently in different situations (that's there purpose!) --- which means that the application is less predictable unless the user exactly understands how the heuristic works... Therefore, I would try to stay away from heuristics if possible, unless they are absolutely intuitive (and the heuristic that I provided above, I think, is not so intuitive). And, the fact is, I think that in this specific case, LyX's behavior is perfectly logical and intuitive, and almost always what I want it to be. If you think otherwise, please explain again exactly what the specific situation is, how you got to that situation, and what you think LyX *should* do in that case... I don't agree with you that lyx's behavior is perfectly logical and intuitive on this issue. You have open office by your side, as it behaves in the same (annoying) way (logical). I see your point about heuristics being bad, I agree with that. We have two conflicting demands here - You seem to like continuous typing and expect that F12 pressed (the second time) will jump to the end of the foreign text so that you can continue typing. That is a good expectation. What I expect is that when I see the cursor in one position, the characters I type will actually get inserted IN THAT POSITION. You can get used to pressing END (it seems that I somehow learned to do that using Word), and I can get used to going back one space and continuing from there, but which is more intuitive and less confusing? I think the confusing part is when the cursor jumps. You seem to already know that the cursor will jump and it doesn't bother you. It is very annoying to me that I have to understand about borders between RTL and LTR and to know that lyx isn't going to continue where the cursor is. We need a mediator to rule, but it seems that you will be writing the code, so you have an advantage :) Miki
Re: user auth patches
Tor Lillqvist wrote: The SID is a structure but there exists a functions for serialization, ConvertSidToStringSid. Therefore a string would be fine, the questions remains if we should use a wchar_t or char? The serialization is always ASCII only, so I don't see any gain in using wide characters. We could also use a copy of the struct if it can be assigned by value and has a fixed size It's variable length structure. --tml What about using internally a DBusString*, and to return a SID by the public API? Peter
Re: user auth patches
Peter Kümmel wrote: Tor Lillqvist wrote: The SID is a structure but there exists a functions for serialization, ConvertSidToStringSid. Therefore a string would be fine, the questions remains if we should use a wchar_t or char? The serialization is always ASCII only, so I don't see any gain in using wide characters. We could also use a copy of the struct if it can be assigned by value and has a fixed size It's variable length structure. --tml What about using internally a DBusString*, and to return a SID by the public API? Peter Sorry, ;) The result of the reply rules: I press reply and choose the mailing list.
Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Dov Feldstern wrote: Dov Feldstern wrote: Miki Dovrat wrote: I was going to say, let the cursor always stay where it is, and the user will learn to press END (end of line) to move it to continue typing. It is logical, (not in the logical direction sense), expected and easily adapted to by the user, as there are no surprises there. It doesn't seem logical at all to me, though I guess I user could get used to it. But I'm glad you've dropped this idea... ;) Abdel's idea is even better. I second it. When writing, lyx will assume you want to jump to the end of line, but when editing, it will assume you don't!! How does one differentiate between writing and editing? By whether I'm at the end of a paragraph or not? This is what (I think) I said somewhere in this thread: in order to get the behavior to be more intuitive, you have to start using heuristics which try to figure out what did the user mean this time?. And the nature of heuristics is that they are sometimes right, sometimes wrong; and they certainly make the code more complicated. So yes, it's a possibility, but we should consider carefully if the heuristics are correct, and whether we want to implement them in each case... Also, heuristics make the application behave differently in different situations (that's there purpose!) --- which means that the application is less predictable unless the user exactly understands how the heuristic works... Therefore, I would try to stay away from heuristics if possible, unless they are absolutely intuitive (and the heuristic that I provided above, I think, is not so intuitive). And, the fact is, I think that in this specific case, LyX's behavior is perfectly logical and intuitive, and almost always what I want it to be. If you think otherwise, please explain again exactly what the specific situation is, how you got to that situation, and what you think LyX *should* do in that case... Dov, did you direct me to here in response to bug 3011? Well, anyway, your fix for 3011 is working. I have version 18791. Miki I have found something very strange!!! a feature? Try this: I changed my document to Hebrew, so that English gets marked foreign. Type a line (starting with RTL) such as LTR LTR LTR RTL RTL RTL Now, in the border between LTR and RTL, to the LEFT of the space, it would seem that this is one cursor position, but with the mouse I can actually hit TWO points there (still to the left of the space but to the right of the English writing): one position continues the Hebrew, and the other position continues the English (the cursor is underlined). Now, it would seem that IF the arrow keys could move through these two states (in our future visual mode, where the cursor will move without jumping to the beginning of English, but through the end of it) it would solve our conflict, as the cursor will tell us what is going to happen while editing. When you come from RTL, it will first be RTL, another - will move you to LTR (the end of it), and other - will move you backwards in the English, and while typing you would keep moving to the end of the line when pressing F12 for continuous typing like you want (which makes more sense to me now). That is OK by me, and it will actually be very good I think. What do you think? Currently, the arrow keys miss the continue English writing position since the behavior is logical, and the cursor goes directly to (ONE AFTER) the beginning of the English in logical mode. I still don't understand why it jumps to one after the beginning of the foreign part. It could have easily have jumped to the beginning of English. Miki
[patch] cursor position update, cursor often stays at old position
Here is a patch for the following problem:
Write something in a Standard layout paragraph. Change it into
Title.
The cursor will stay at the old position until the cursor blink
interval is over
There are many more those cases: Try to insert a math delimiter (Alt-
m (). The cursor stays outside of the math and then jump into it on
the next blinking interval. There is also a bug report for that, but
cannot find it currently.
Anyway, here is a patch.
Stefan
Index: src/frontends/WorkArea.cpp
===
--- src/frontends/WorkArea.cpp (Revision 18792)
+++ src/frontends/WorkArea.cpp (Arbeitskopie)
@@ -144,6 +144,13 @@
updateScrollbar();
+ // update cursor position, because otherwise it has to wait until
+ // the blinking interval is over
+ if (cursor_visible_) {
+ hideCursor();
+ showCursor();
+ }
+
ViewMetricsInfo const vi = buffer_view_-viewMetricsInfo();
greyed_out_ = false;
cursorupdate.patch
Description: Binary data
PGP.sig
Description: Signierter Teil der Nachricht
Re: [patch] cursor position update, cursor often stays at old position
The bug report: http://bugzilla.lyx.org/show_bug.cgi?id=3854 Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] cursor position update, cursor often stays at old position
And one about the described general problem: http://bugzilla.lyx.org/ show_bug.cgi?id=3873 Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Richard Heck wrote: Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is called from LyXView::loadLyXFile(), anyway, all the child doc stuff could be moved there. But I don't know this code terribly well. Abdel? Very good analysis Richard! The solution is to use the LFUN instead of using loadLyXFile from buffer_funcs.cpp. This should fix the problem. Thanks, Abdel.
Re: [PATCH] Bug 3860 Toc crash when loading a child documents
Stefan Schimanski wrote: Tried it a bit with child documents. Looks fine. OK, thanks. Abdel.
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Abdelrazak Younes wrote:
Richard Heck wrote:
Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is
called from LyXView::loadLyXFile(), anyway, all the child doc stuff
could be moved there. But I don't know this code terribly well. Abdel?
Very good analysis Richard! The solution is to use the LFUN instead of
using loadLyXFile from buffer_funcs.cpp. This should fix the problem.
Does this patch (on top of the other) fixes the problem?
Abdel.
Index: InsetInclude.cpp
===
--- InsetInclude.cpp(revision 18780)
+++ InsetInclude.cpp(working copy)
@@ -26,6 +26,7 @@
#include gettext.h
#include LaTeXFeatures.h
#include LyX.h
+#include LyXFunc.h
#include LyXRC.h
#include Lexer.h
#include MetricsInfo.h
@@ -400,12 +401,10 @@
// the readonly flag can/will be wrong, not anymore I think.
if (!fs::exists(included_file.toFilesystemEncoding()))
return false;
- buf = theBufferList().newBuffer(included_file.absFilename());
- if (!loadLyXFile(buf, included_file)) {
- //close the buffer we just opened
- theBufferList().close(buf, false);
- return false;
- }
+ dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN,
+ included_file.absFilename()));
+ buf = theBufferList().getBuffer(included_file.absFilename());
+ return buf;
}
buf-setParentName(parentFilename(buffer));
return true;
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Richard Heck wrote: Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is called from LyXView::loadLyXFile(), anyway, all the child doc stuff could be moved there. Of course you are right but I don't want to do that now because it will involves much more intrusive changes in BufferView. I've added a FIXME for that in my patch by the way. The solution with the LFUN dispatching is good enough for now. In 1.6 we will remove this method and also setBuffer() from BufferView anyway. Abdel.
Re: [patch] cursor position update, cursor often stays at old position
Here is a patch for the following problem: Write something in a Standard layout paragraph. Change it into Title. The cursor will stay at the old position until the cursor blink interval is over I also noticed this problem since a while. The patch seems obvious and fixes the problems for me, so I give an OK. regards Uwe
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Abdelrazak Younes wrote: Richard Heck wrote: Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is called from LyXView::loadLyXFile(), anyway, all the child doc stuff could be moved there. But I don't know this code terribly well. Abdel? Very good analysis Richard! The solution is to use the LFUN instead of using loadLyXFile from buffer_funcs.cpp. This should fix the problem. Do you mean to call LFUN_BUFFER_CHILD_OPEN from InsetInclude? The problem with doing it that way, and a more general problem, actually---you'd get the same problem if you could somehow call LyXFunc::loadLyXFile() directly---is that this will reset the buffer. I.e., focus will switch to the new buffer, which is not what we want for these automatic loads. I think that's basically why loadLyXFile() is being called directly: to skip all that stuff. But we end up skipping too much. But it still seems right to call the LyXView version one way or another. I don't know what to do here. One option would be to add another flag to LyXView::loadLyXFile() and in BufferView::loadLyXFile(), something like bool setFocus = true, and then we'd do something like this in the latter: if (setFocus) setBuffer(b); and in the former: bool const loaded = work_area_-bufferView().loadLyXFile(filename, setFocus); But then if we're calling this via an LFUN, we'll need a new LFUN to do it with, or else add a flag somehow to LFUN_BUFFER_CHILD_OPEN and make appropriate changes there. Is there a style for such flags? We can't use, say, | as a separator, because that could occur in a filename. So could anything else. So I'm not sure how to proceed there. So maybe a new LFUN, LFUN_BUFFER_CHILD_AUTO_OPEN (?) is needed. Thoughts? Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [patch] cursor position update, cursor often stays at old position
I also noticed this problem since a while. The patch seems obvious and fixes the problems for me, so I give an OK. Will be away until Sunday/Monday. Feel free to commit it. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is
called from LyXView::loadLyXFile(), anyway, all the child doc stuff
could be moved there. But I don't know this code terribly well. Abdel?
Very good analysis Richard! The solution is to use the LFUN instead
of using loadLyXFile from buffer_funcs.cpp. This should fix the problem.
Does this patch (on top of the other) fixes the problem?
I'm checking this now, but I think it will have the problem I mentioned
in the last email: We'll end up switching open buffers. Also needed a
small change...
rh
Index: InsetInclude.cpp
===
--- InsetInclude.cpp(revision 18780)
+++ InsetInclude.cpp(working copy)
@@ -26,6 +26,7 @@
#include gettext.h
#include LaTeXFeatures.h
#include LyX.h
+#include LyXFunc.h
#include LyXRC.h
#include Lexer.h
#include MetricsInfo.h
@@ -400,12 +401,10 @@
// the readonly flag can/will be wrong, not anymore I think.
if (!fs::exists(included_file.toFilesystemEncoding()))
return false;
- buf = theBufferList().newBuffer(included_file.absFilename());
- if (!loadLyXFile(buf, included_file)) {
- //close the buffer we just opened
- theBufferList().close(buf, false);
- return false;
- }
What follows has to be const_castBuffer (buffer).dispatch().
+ dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN,
+ included_file.absFilename()));
+ buf = theBufferList().getBuffer(included_file.absFilename());
+ return buf;
}
buf-setParentName(parentFilename(buffer));
return true;
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Richard Heck wrote: Abdelrazak Younes wrote: Richard Heck wrote: Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is called from LyXView::loadLyXFile(), anyway, all the child doc stuff could be moved there. But I don't know this code terribly well. Abdel? Very good analysis Richard! The solution is to use the LFUN instead of using loadLyXFile from buffer_funcs.cpp. This should fix the problem. Do you mean to call LFUN_BUFFER_CHILD_OPEN from InsetInclude? Yes, see just posted patch. The problem with doing it that way, and a more general problem, actually---you'd get the same problem if you could somehow call LyXFunc::loadLyXFile() directly---is that this will reset the buffer. Right, this is a minor inconvenience indeed. I.e., focus will switch to the new buffer, which is not what we want for these automatic loads. I think that's basically why loadLyXFile() is being called directly: to skip all that stuff. But we end up skipping too much. But it still seems right to call the LyXView version one way or another. I don't know what to do here. One option would be to add another flag to LyXView::loadLyXFile() and in BufferView::loadLyXFile(), something like bool setFocus = true, and then we'd do something like this in the latter: if (setFocus) setBuffer(b); and in the former: bool const loaded = work_area_-bufferView().loadLyXFile(filename, setFocus); But then if we're calling this via an LFUN, we'll need a new LFUN to do it with, or else add a flag somehow to LFUN_BUFFER_CHILD_OPEN and make appropriate changes there. Is there a style for such flags? We can't use, say, | as a separator, because that could occur in a filename. So could anything else. So I'm not sure how to proceed there. So maybe a new LFUN, LFUN_BUFFER_CHILD_AUTO_OPEN (?) is needed. Thoughts? I don't like the idea of a new LFUN so what about switching back to the parent Buffer in loadIfNeeded() instead? The side effect is that you will see the child documents loaded one by one but at the end the focus will come back to the master document. What do you think? Abdel.
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Richard Heck wrote: Abdelrazak Younes wrote: Abdelrazak Younes wrote: Richard Heck wrote: Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is called from LyXView::loadLyXFile(), anyway, all the child doc stuff could be moved there. But I don't know this code terribly well. Abdel? Very good analysis Richard! The solution is to use the LFUN instead of using loadLyXFile from buffer_funcs.cpp. This should fix the problem. Does this patch (on top of the other) fixes the problem? I'm checking this now, but I think it will have the problem I mentioned in the last email: We'll end up switching open buffers. Yes. Also needed a small change... What follows has to be const_castBuffer (buffer).dispatch(). No, I want rather to use the global dispatch method. So that would be: +lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN, MSVC chose this one automatically for me but I'll do the change anyway. Thanks. Abdel.
Re: [patch] cursor position update, cursor often stays at old position
Stefan Schimanski wrote: I also noticed this problem since a while. The patch seems obvious and fixes the problems for me, so I give an OK. Will be away until Sunday/Monday. Feel free to commit it. You have my OK if you want to commit now ;-) Abdel.
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Abdelrazak Younes wrote: Richard Heck wrote: What follows has to be const_castBuffer (buffer).dispatch(). No, I want rather to use the global dispatch method. So that would be: +lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN, MSVC chose this one automatically for me but I'll do the change anyway. Thanks. gcc choked automatically. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: RC2 coming soon
José Matos wrote:
Hi all,
I will start looking to remaining issues before RC2, AFAIR there are two
patches that I would like to have before the release, one by Jürgen that has
a file format change and another related with reverting documents to 1.4.
Is there anything else that I am missing before RC2?
tearing of math panels using attached patch?
Index: src/frontends/qt4/IconPalette.cpp
===
--- src/frontends/qt4/IconPalette.cpp (revision 18792)
+++ src/frontends/qt4/IconPalette.cpp (working copy)
@@ -24,17 +24,100 @@
#include QPainter
#include QStyle
#include QStyleOptionFrame
+#include QMouseEvent
namespace lyx {
namespace frontend {
+#if QT_VERSION = 0x040200
+
+
+class MathButton : public QToolButton
+{
+public:
+ MathButton(QWidget * parent = 0) {}
+ void mouseReleaseEvent(QMouseEvent *event);
+ void mousePressEvent(QMouseEvent *event);
+};
+
+
+void MathButton::mouseReleaseEvent(QMouseEvent *event)
+{
+ QToolButton::mouseReleaseEvent(event);
+ event-ignore();
+}
+
+
+void MathButton::mousePressEvent(QMouseEvent *event)
+{
+ QToolButton::mousePressEvent(event);
+ event-ignore();
+}
+
+
IconPalette::IconPalette(QWidget * parent)
+ : QWidgetAction(parent), size_(QSize(22, 22))
+{
+}
+
+
+void IconPalette::addButton(QAction * action)
+{
+ actions_.push_back(action);
+}
+
+
+QWidget * IconPalette::createWidget(QWidget * parent)
+{
+ QWidget * widget = new QWidget(parent);
+ QGridLayout * layout = new QGridLayout(widget);
+ layout-setSpacing(0);
+
+ for (int i = 0; i actions_.size(); ++i) {
+ MathButton * tb = new MathButton(widget);
+ tb-setAutoRaise(true);
+ tb-setDefaultAction(actions_.at(i));
+ tb-setIconSize(size_);
+ connect(this, SIGNAL(iconSizeChanged(const QSize )),
+ tb, SLOT(setIconSize(const QSize )));
+
+ int const row = i/qMin(6, i + 1) + 1;
+ int const col = qMax(1, i + 1 - (row - 1) * 6);
+ layout-addWidget(tb, row, col);
+ }
+
+ return widget;
+}
+
+
+void IconPalette::setIconSize(const QSize size)
+{
+ size_ = size;
+ // signal
+ iconSizeChanged(size);
+}
+
+
+void IconPalette::updateParent()
+{
+ bool enable = false;
+ for (int i = 0; i actions_.size(); ++i)
+ if (actions_.at(i)-isEnabled()) {
+ enable = true;
+ break;
+ }
+ // signal
+ enabled(enable);
+}
+
+#else // QT_VERSION = 0x040200
+
+IconPalette::IconPalette(QWidget * parent)
: QWidget(parent, Qt::Popup)
{
layout_ = new QGridLayout(this);
- layout_-setSpacing(0);
- layout_-setMargin(3);
- setLayout(layout_);
+ layout-setSpacing(0);
+ layout-setMargin(3);
}
@@ -151,6 +234,7 @@
// draw the rest (buttons)
QWidget::paintEvent(event);
}
+#endif // QT_VERSION = 0x040200
ButtonMenu::ButtonMenu(const QString title, QWidget * parent)
Index: src/frontends/qt4/IconPalette.h
===
--- src/frontends/qt4/IconPalette.h (revision 18792)
+++ src/frontends/qt4/IconPalette.h (working copy)
@@ -17,12 +17,40 @@
#include QLayout
#include Action.h
+// FIXME: this can go when we move to Qt 4.3
+#define QT_VERSION_CHECK(major, minor, patch) ((major16)|(minor8)|(patch))
+
+#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#include QWidgetAction
+#endif
+
namespace lyx {
namespace frontend {
/**
* For holding an arbitrary set of icons.
*/
+#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+
+class IconPalette : public QWidgetAction {
+ Q_OBJECT
+public:
+ IconPalette(QWidget * parent);
+ void addButton(QAction *);
+ QWidget * createWidget(QWidget * parent);
+public Q_SLOTS:
+ void updateParent();
+ void setIconSize(const QSize );
+Q_SIGNALS:
+ void enabled(bool);
+ void iconSizeChanged(const QSize );
+private:
+ QListQAction * actions_;
+ QSize size_;
+};
+
+#else
+
class IconPalette : public QWidget {
Q_OBJECT
public:
@@ -49,6 +77,8 @@
QListQAction * actions_;
};
+#endif // QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+
/**
* Popup menu for a toolbutton.
* We need this to keep track whether
Index: src/frontends/qt4/QLToolbar.cpp
===
--- src/frontends/qt4/QLToolbar.cpp (revision 18792)
+++ src/frontends/qt4/QLToolbar.cpp (working copy)
@@ -40,7 +40,6 @@
#include QAction
#include QPixmap
-
namespace lyx {
using std::string;
@@ -207,14 +206,21 @@
}
case ToolbarItem::ICONPALETTE: {
QToolButton * tb = new QToolButton(this);
- tb-setCheckable(true);
tb-setToolTip(qt_(to_ascii(item.label_)));
tb-setStatusTip(qt_(to_ascii(item.label_)));
tb-setText(qt_(to_ascii(item.label_)));
connect(this, SIGNAL(iconSizeChanged(const QSize )),
tb, SLOT(setIconSize(const QSize )));
+#if QT_VERSION = 0x040200
+ IconPalette * panel = new IconPalette(owner_);
+ connect(panel, SIGNAL(enabled(bool)),
+ tb, SLOT(setEnabled(bool)));
+ connect(this, SIGNAL(iconSizeChanged(const QSize )),
+ panel, SLOT(setIconSize(const QSize )));
+#else
IconPalette * panel = new IconPalette(tb);
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Abdelrazak Younes wrote: Richard Heck wrote: What follows has to be const_castBuffer (buffer).dispatch(). No, I want rather to use the global dispatch method. So that would be: +lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN, MSVC chose this one automatically for me but I'll do the change anyway. Thanks. I also had to add: extern void dispatch(FuncRequest const action); to get it to compile. This isn't declared in LyX.h for some reason. Now that it does compile, I can confirm that...it segfaults. What I send up seeing is a billion calls to getMasterBuffer(). The problem has to do with how parentname is being set. One of my child docs is turning out to be its own parent. This is a consequence of the inconvenience we were discussing before, namely, that the active buffer is being reset on each call. If I break in LyXFunc::loadLyXFilename(), I can see that the wrong buffer is being set as parent. Here's what happens: Master includes Child1; open that, now Child1 is active; the parent of Child1 is now set to Master. Master also includes Child2; so we open that, and now it is active; the parent of Child2 is set to Child1, since that is the active buffer; Child2 includes Child1; that's already open, but now we reset the parent of Child1 to Child2. We now have a loop, since Child2 is Child1's parent and conversely, and we crash in getMasterBuffer(). But even if we didn't get that loop, the parentname would still be wrong. However that gets sorted out, this: newBuffer-setParentName(parentfilename); should perhaps be done only if newBuffer doesn't already have a parent set. So something like: if (!newBuffer-params()-parentname) ... Or maybe we want to reset the parent. This must be related to the multiple inclusion issue someone mentioned a bit ago. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Richard Heck wrote: Abdelrazak Younes wrote: Richard Heck wrote: What follows has to be const_castBuffer (buffer).dispatch(). No, I want rather to use the global dispatch method. So that would be: +lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN, MSVC chose this one automatically for me but I'll do the change anyway. Thanks. I also had to add: extern void dispatch(FuncRequest const action); to get it to compile. This isn't declared in LyX.h for some reason. That is in LyXFunc.h, I'll fix that too, thanks. Now that it does compile, I can confirm that...it segfaults. What I send up seeing is a billion calls to getMasterBuffer(). The problem has to do with how parentname is being set. One of my child docs is turning out to be its own parent. This is a consequence of the inconvenience we were discussing before, namely, that the active buffer is being reset on each call. If I break in LyXFunc::loadLyXFilename(), I can see that the wrong buffer is being set as parent. I see. Now that I know all use cases, let me think a bit about it, I'll try to come up with a clean solution during the week-end. Maybe the only clean way is to remove loadLyXFile from LyXView and BufferView altogether. Thanks for the help and testing. Abdel. Here's what happens: Master includes Child1; open that, now Child1 is active; the parent of Child1 is now set to Master. Master also includes Child2; so we open that, and now it is active; the parent of Child2 is set to Child1, since that is the active buffer; Child2 includes Child1; that's already open, but now we reset the parent of Child1 to Child2. We now have a loop, since Child2 is Child1's parent and conversely, and we crash in getMasterBuffer(). But even if we didn't get that loop, the parentname would still be wrong. However that gets sorted out, this: newBuffer-setParentName(parentfilename); should perhaps be done only if newBuffer doesn't already have a parent set. So something like: if (!newBuffer-params()-parentname) ... Or maybe we want to reset the parent. This must be related to the multiple inclusion issue someone mentioned a bit ago. Richard
Re: [patch] cursor position update, cursor often stays at old position
Stefan Schimanski schrieb: Will be away until Sunday/Monday. Feel free to commit it. Abdel gave his OK too, so committed it for you: http://www.lyx.org/trac/changeset/18799 regards Uwe
Re: [PATCH] Bug 3860 Toc crash WITH child documents
Abdelrazak Younes wrote: Richard Heck wrote: Abdelrazak Younes wrote: Richard Heck wrote: What follows has to be const_castBuffer (buffer).dispatch(). No, I want rather to use the global dispatch method. So that would be: +lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN, MSVC chose this one automatically for me but I'll do the change anyway. Thanks. I also had to add: extern void dispatch(FuncRequest const action); to get it to compile. This isn't declared in LyX.h for some reason. That is in LyXFunc.h, I'll fix that too, thanks. Now that it does compile, I can confirm that...it segfaults. What I send up seeing is a billion calls to getMasterBuffer(). The problem has to do with how parentname is being set. One of my child docs is turning out to be its own parent. This is a consequence of the inconvenience we were discussing before, namely, that the active buffer is being reset on each call. If I break in LyXFunc::loadLyXFilename(), I can see that the wrong buffer is being set as parent. I see. Now that I know all use cases, let me think a bit about it, I'll try to come up with a clean solution during the week-end. Maybe the only clean way is to remove loadLyXFile from LyXView and BufferView altogether. Thanks for the help and testing. No problem. One of the things I like about this is the teamwork. And being able to learn from people who've been at it a while. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: RC2 coming soon
tearing of math panels using attached patch? We are also finding a second home for aspell dictionaries so that the windows installer will work even ftp.lyx.org is unusable. Bo
Re: [patch] tex2lyx crash when full path is given from commandline on Win32
We've been relaxing the rules lately; support/ uses QtCore for a number of things and I think it would be much saner at this point to use QFileInfo, QProcess and QNetwork to replace our hand-made local code. If somebody steps up to encapsulate this Qt API in our API (forkedControllers, Socket and FileName) he will have at least my full support (and help) and probably not much resistance from others. But it needs a _lot_ of change. All file open/create must be patched. As a result, the work needs the involvement of the whole lyx development community. It's kind of impossible thing for me. And I don't think it's worth to do so. Certainly, if this problem lies not only on Windows but also on other platforms, it may worth to have a though clean of the code. And I just tested that Qt converts the filenames between local encoding and UTF-32 correctly. So the evil is solely from M$'s disgusting stdc++ library. I really hate this -- even though Win32 API supports local encoding very well, M$'s clib breaks it completely.. I'm trying to hack the disgusting M$ stdc++ library to allow proper local 8-bit filename support. In that way we do not need to patch anything other than M$ library. And one programer is enough. If this problem affects only Windows, I believe it's good enough. Now the remaining problem is to test whether other platforms and compilers/stdc++ libararies have the same problem. I do not have access to such platforms so I can't do the test. Could anyone help to test it? Hangzai
Re: Sample test files and improved patch Re: [patch] Enable tex2lyx read back lyx exported .tex as much as possible
I'm glad to receive so many feedbacks for my patch :-)
And here I have to tell you some of my thoughts:
1. I made this patch is because I need it. I have to
convert .tex files including those features, and
convert between .tex and .lyx back and forth. I met
these problems addressed in the patch, and lucky
I'm a programmer, so I can make a patch to improve
it: that's one of the most important reason that we
support open source. Certainly the patch has a _lot_
of problems, as it's just assumed to be used by myself.
And your feedbacks will certainly be considered to
make better version. It's absolutely OK for me whether
this patch is accepted or not, because I can always
compile my patched version, and I have several other
patches for lyx. I put it here just in case someone
else may need it, and get some idea how this problem
affects others.
2. I also dislike current tex2lyx structure. But I also
dislike the idea of python script. If let me make the
choice, I will choose flex, or flex+bison. Flex syntax
is extremely suitable for parsers, for both programming
and maintenance. I don't see any advantage of python
at this point. Certainly, flex in it's original state
is not suitable to be used to develop tex2lyx. We need
several distict features that are not supported by
original flex. But we can make our improved flex.
And it's not difficult at all. I believe we just need
to have a new template for the code generation. I have
used flex as this way, and I have a template that is
able to support true C++ lexer, abstract input/output,
etc. If needed, I can distribute my work to this community
and make some improvements to satisfy the tex2lyx needs.
And, another benefit of flex is speed. I assure it will
be much faster than current C++ code.
3. I want the integration of tex2lyx with lyx a lot. Indeed
I'm working on a patch to enable relyx upon paste. I posted
one patch several weeks ago to enable relyx \cite{...}. If
the integration is achieved, then this part of work is much
easier. And, the integration is another support for using
flex to develop tex2lyx.
4. As of incorrect file format, my idea is, if tex2lyx+lyx2lyx
produces correct output, we can think it's OK. Because we always
go tex2lyx+lyx2lyx. If needed, we can call lyx2lyx in tex2lyx,
so that the final output of tex2lyx is absolutely valid. And in
this way, the encoding problem is also solved.
5. Even though we have new implementation of tex2lyx planned,
we can still make small imporvements on current tex2lyx.
I don't care whether it will get lost, as it just costs
me one or two days. But it will save me significantly
on my work before the new implementation is available.
As I said above, I need these features badly. And such
work will give us the information of what kind of features
are useful and should be supported in new implementation.
So, I think completely halting the development of tex2lyx
is incorrect. We can still make small improvements.
Above are IMHO certainly :-) And now our major problem
is to decide a direction of future tex2lyx ASAP.
We now have severaly completely different proposals.
How can we make the decision?
Regards,
Hangzai
[patch] Space displayed after macro, #3705
Here is a patch for http://bugzilla.lyx.org/show_bug.cgi?id=3705. It
adds the kerning method to a macro to inherit the kerning from the
expanded form. Moreover the marker metrics calls are remove as they
are not drawn anyway.
Stefan
Index: src/mathed/MathMacro.h
===
--- src/mathed/MathMacro.h (Revision 18774)
+++ src/mathed/MathMacro.h (Arbeitskopie)
@@ -54,6 +54,8 @@
///
docstring name() const;
///
+ int kerning() const { return kerning_; }
+ ///
void setExpansion(MathData const & exp, MathData const & args) const;
///
@@ -85,6 +87,8 @@
mutable MacroData macroBackup_;
///
mutable bool editing_;
+ ///
+ mutable int kerning_;
};
Index: src/mathed/MathMacro.cpp
===
--- src/mathed/MathMacro.cpp(Revision 18774)
+++ src/mathed/MathMacro.cpp(Arbeitskopie)
@@ -44,6 +44,8 @@
bool metrics(MetricsInfo & mi, Dimension & dim) const;
///
void draw(PainterInfo &, int x, int y) const;
+ ///
+ int kerning() const { return mathMacro_.cell(idx_).kerning(); }
private:
std::auto_ptr doClone() const;
@@ -65,7 +67,6 @@
macro.unlock();
mathMacro_.cell(idx_).metrics(mi, dim);
macro.lock();
- metricsMarkers2(dim);
if (dim_ == dim)
return false;
dim_ = dim;
@@ -114,6 +115,7 @@
bool MathMacro::metrics(MetricsInfo & mi, Dimension & dim) const
{
+ kerning_ = 0;
if (!MacroTable::globalMacros().has(name())) {
mathed_string_dim(mi.base.font, "Unknown: " + name(), dim);
} else {
@@ -143,10 +145,10 @@
macro.lock();
expanded_.metrics(mi, dim);
macro.unlock();
+ kerning_ = expanded_.kerning();
editing_ = false;
}
}
- metricsMarkers2(dim);
if (dim_ == dim)
return false;
dim_ = dim;
@@ -199,7 +201,6 @@
if (editing_ != editing(pi.base.bv) || macroBackup_ != macro)
pi.base.bv->cursor().updateFlags(Update::Force);
}
- drawMarkers2(pi, x, y);
}
macrospacearound.patch
Description: Binary data
PGP.sig
Description: Signierter Teil der Nachricht
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Hi,
My comments are below
Miki
3. If I have a Hebrew paragraph with an English word like
? English ? ?
and I type continuously, the spaces are Hebrew. Now if I try to
continue the Hebrew to the right of the English word, but after the
Hebrew space, as to continue typing, I can't: If I am in English mode
and I press F12 (bound to language hebrew), the cursor jumps to the
left of the English word. If I was already in hebrew (if the cursor was
resting on a hebrew word before and then I moved it to this position
with the mouse), then it's ok.
>>> This is correct. If you move to the right of the english through the
>>> english, then at the end you are still considered to be in English, at
>>> the end of the english; so switching to hebrew should move you to the
>>> left of the english. You can do what you want by moving to the beginning
>>> of the english, and then move back one more, that'll bring you to the
>>> space before the english; then if you move one Left, you'll be after the
>>> space, but still in hebrew. Typing in hebrew will then work as you want
>>> it to.
>>
>> What you say is correct, and I have found that out, but it is not
>> intuitive
>> and takes "learning" lyx's behavior.
>> Also, when you just land there with the mouse, you have the same
>> "problem".
>
> Can you think of a sane way to solve this?
>
> What do you want LyX to do: to say that if you've been typing in english
> and then switch the language to hebrew, that it should jump back to before
> the english, and continue inserting the hebrew there? 'cause I think
> that's what would be necessary to do what you want in this case --- but
> then just plain typing in would be a real pain: you type some hebrew, want
> to insert a word in english so you switch to english, type the word, then
> switch back to hebrew (you want to continue typing ---
> after the english word, of course) and find yourself before the english
> word!
>
> I don't see any way out. And BTW, I'm not sure --- but I don't think that
> visual mode will solve this, either...
I would like lyx to be visual, and I think it will solve this problem, since
the cursor will STAY PUT in the location it is in without jumping anywhere.
In latex, you will have \L's and \R's all over the place, and you can clean
that up "later" - maybe when saving, maybe when leaving the row. I don't
know enough about what lyx does (I wanted to get into it but I lack the
time, maybe in the future...)
To sum up, I would like lyx, when it is inside a \L (English), to switch
automatically to English, unless the user explicitly changes it with F12
(\language hebrew), the cursor will NOT MOVE, and the text will be added
where it was, whether it was English or Hebrew.
When moving across already written text, lyx, when spotting a move between
\L and \R should move visually, i.e., to the end of the foreign text and go
backwards (so the arrow keys move to the right direction), and change its
language as well, again, unless explicitly changed by the user by pressing
F12.
Lyx should then understand about spaces being adjacent visually, not
logically, and fix adjacent spaces between RTL and LTR this way.
Is that not simpler to understand, as far as a user is concerned? I am not
referring to coding problems here. Can that be accomplished?
>>
6. I cannot enter an inline equation to the right of the English word.
>>> This looks like a bug. If you're coming from the english, then I think
>>> that the equation should also be "in english" (see next comment), and
>>> then what you want to do would work. Can you open a bug for this in
>>> bugzilla (and see next comment)? Meanwhile, if you just select the
>>> entire inset, and switch it's language with F12, you'll get what you
>>> want.
>>
>> This is bug 3011 in bugzilla.
>>
>
> See the fix I sent separately...
>
>>> 7, 8 seem to be the same issue as in 6...?
>>
>> Probably. I am not entering them as a separate bug for now.
>>
>
> Are these solved with the above-mentioned fix?
Is it already in svn? if not, where is the patch? I will check.
10. References which get added RTL are backward in output, i.e. instead
of 12, 13, 14, etc. I get 21, 31, 41. Even if I try to switch the
language to English, the reference gets marked RTL. I suspect it will
be the same for figure numbers above 10. For equations it comes out
fine for some reason even above 10.
>>> Is the problem here in the display or in latex or both? I haven't
>>> checked this yet...
>>
>> This is bug 3005. The output (DVI) comes out reversed. On screen you
>> don't
>> see numbers anyway, you see labels. The references are inside the \R{ }
>> in
>> latex and that is the problem I guess.
>>
>
> Hmmm... I see that this was like that in 1.3.X, too, so it's not a
> regression. Any ideas on how to solve it? There are a few issues for which
> "I know" what needs to be done
Re: [patch] Language of Inset (bug 3011)
Dov Feldstern wrote:
Jean-Marc Lasgouttes wrote:
"Dov" == Dov Feldstern
<[EMAIL PROTECTED]> writes:
Dov> Hi! attached find a very simple fix for
Dov> http://bugzilla.lyx.org/show_bug.cgi?id=3011 (which is a
Dov> regression relative to 1.3.X). The problem is that when typing
Dov> some LTR in an RTL paragraph (or vice versa), when an inset is
Dov> inserted, it gets inserted in the paragraph language, and not in
Dov> the current language. It's more correct for the inset to be
Dov> inserted in the current language. That's what this patch
Dov> achieves.
Is there a reason why you use real_current_font instead of
current_font? The later is the non-expanded version, which is IMO
better.
Attached is the patch using current_font. Is this Okay?
Dov
Index: lyx-devel/src/Text2.cpp
===
--- lyx-devel.orig/src/Text2.cpp2007-06-14 23:46:30.0 +0300
+++ lyx-devel/src/Text2.cpp 2007-06-14 23:48:16.0 +0300
@@ -670,7 +670,7 @@
{
BOOST_ASSERT(this == cur.text());
BOOST_ASSERT(inset);
- cur.paragraph().insertInset(cur.pos(), inset,
+ cur.paragraph().insertInset(cur.pos(), inset, current_font,
Change(cur.buffer().params().trackChanges ?
Change::INSERTED :
Change::UNCHANGED));
}
was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Separating this into different issues, it's getting long... Miki Dovrat wrote: 3. If I have a Hebrew paragraph with an English word like ? English ? ? and I type continuously, the spaces are Hebrew. Now if I try to continue the Hebrew to the right of the English word, but after the Hebrew space, as to continue typing, I can't: If I am in English mode and I press F12 (bound to language hebrew), the cursor jumps to the left of the English word. If I was already in hebrew (if the cursor was resting on a hebrew word before and then I moved it to this position with the mouse), then it's ok. This is correct. If you move to the right of the english through the english, then at the end you are still considered to be in English, at the end of the english; so switching to hebrew should move you to the left of the english. You can do what you want by moving to the beginning of the english, and then move back one more, that'll bring you to the space before the english; then if you move one Left, you'll be after the space, but still in hebrew. Typing in hebrew will then work as you want it to. What you say is correct, and I have found that out, but it is not intuitive and takes "learning" lyx's behavior. Also, when you just land there with the mouse, you have the same "problem". Can you think of a sane way to solve this? What do you want LyX to do: to say that if you've been typing in english and then switch the language to hebrew, that it should jump back to before the english, and continue inserting the hebrew there? 'cause I think that's what would be necessary to do what you want in this case --- but then just plain typing in would be a real pain: you type some hebrew, want to insert a word in english so you switch to english, type the word, then switch back to hebrew (you want to continue typing --- after the english word, of course) and find yourself before the english word! I don't see any way out. And BTW, I'm not sure --- but I don't think that visual mode will solve this, either... I would like lyx to be visual, and I think it will solve this problem, since the cursor will STAY PUT in the location it is in without jumping anywhere. That will work when moving, but not when typing: when you type in hebrew, and then switch to english, and then back to hebrew --- where do you want the hebrew to continue: to the left or to the right of the english? I want it to continue on the left: usually I type in logical order, not first all the hebrew and then go back and insert the english... In latex, you will have \L's and \R's all over the place, and you can clean that up "later" - maybe when saving, maybe when leaving the row. I don't know enough about what lyx does (I wanted to get into it but I lack the time, maybe in the future...) To sum up, I would like lyx, when it is inside a \L (English), to switch automatically to English I believe it does this... , unless the user explicitly changes it with F12 (\language hebrew), the cursor will NOT MOVE, and the text will be added where it was, whether it was English or Hebrew. Again, this doesn't make sense when typing. It means after every insertion of an english word, you'll have to move the cursor before continuing to type in hebrew...
Re: 20% speedup of paragraph redraw with simple patch
Andre Poenitz wrote: On Thu, Jun 14, 2007 at 05:49:53PM +0200, Abdelrazak Younes wrote: Moreover, it remains to be seen whether the map is faster in the cases where the container typically has at most 10 elements. It might be that a stupid plain loop is faster... Maybe not faster but a lot cleaner. You may have noticed that users are complaining about speed, not on code cleanliness. When you quote something please quote the full sentence: "Am I am pretty sure that it will make the cases similar to the one found by Stefan easier to optimize." I end this thread. Abdel.
Re: 20% speedup of paragraph redraw with simple patch
On Thu, Jun 14, 2007 at 09:01:49PM +0200, Andre Poenitz wrote: > On Thu, Jun 14, 2007 at 05:05:32PM +0200, Stefan Schimanski wrote: > > I did some profiling of paragraph drawing. 20% of the whole time > > while inserting characters and redrawing the screen was taken by > > Paragraph::getInset calls, each for every character. This is stupid. > > See the patch below for a loop iterating over the insets of a > > paragraph instead. O(insetnumber) instead of O(charnumber * ln > > insetnumber). > > > > Stefan > > ... > > Good catch. Patch is fine with me. > > [And I continue hating that wide() business ;-}] > > Andre' Come and help rip it out from 1.6 in Bromarv... Abdel's idea is sound and perhaps that's what I should have done in the first place rather than this elaborate hack. - Martin
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Miki Dovrat wrote: When moving across already written text, lyx, when spotting a move between \L and \R should move visually, i.e., to the end of the foreign text and go backwards (so the arrow keys move to the right direction), and change its language as well, again, unless explicitly changed by the user by pressing F12. Regarding visual movement, I agree that it would solve some (not all!) of these issues. But I also think that implementing visual movement correctly will require some refactoring of the cursor movement code. I hope to get working on it soon, but even if it is ready before 1.5.0 is released, I'm not sure that those kinds of changes should go in at this point. And in that case, I'd rather focus in the meantime on issues which can, perhaps, be fixed for 1.5.0.
Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Dov Feldstern wrote: , unless the user explicitly changes it with F12 (\language hebrew), the cursor will NOT MOVE, and the text will be added where it was, whether it was English or Hebrew. Again, this doesn't make sense when typing. It means after every insertion of an english word, you'll have to move the cursor before continuing to type in hebrew... No, in Visual mode, when LyX detect an RTL characters the insertion should happen at the right place. IOW, the jumping will happen at _writing_ time not at cursor navigation time like in so-called 'logical mode'. IMHO of course :-) Abdel.
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Miki Dovrat wrote: To sum up, I would like lyx, when it is inside a \L (English), to switch automatically to English, unless the user explicitly changes it with F12 (\language hebrew), the cursor will NOT MOVE, and the text will be added where it was, whether it was English or Hebrew. When moving across already written text, lyx, when spotting a move between \L and \R should move visually, i.e., to the end of the foreign text and go backwards (so the arrow keys move to the right direction), and change its language as well, again, unless explicitly changed by the user by pressing F12. Lyx should then understand about spaces being adjacent visually, not logically, and fix adjacent spaces between RTL and LTR this way. Is that not simpler to understand, as far as a user is concerned? FWIW I 100% agree with you but I am not (yet) an RTL writer :-) I am not referring to coding problems here. Can that be accomplished? I believe it would be simpler to achieve than the current complicated logical navigation. The difficult part would be the automagic insertion at the right place. Abdel.
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Dov Feldstern wrote: Miki Dovrat wrote: When moving across already written text, lyx, when spotting a move between \L and \R should move visually, i.e., to the end of the foreign text and go backwards (so the arrow keys move to the right direction), and change its language as well, again, unless explicitly changed by the user by pressing F12. Regarding visual movement, I agree that it would solve some (not all!) of these issues. But I also think that implementing visual movement correctly will require some refactoring of the cursor movement code. I hope to get working on it soon, but even if it is ready before 1.5.0 is released, I'm not sure that those kinds of changes should go in at this point. And in that case, I'd rather focus in the meantime on issues which can, perhaps, be fixed for 1.5.0. Agreed :-) Abdel.
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Miki Dovrat wrote: 6. I cannot enter an inline equation to the right of the English word. This looks like a bug. If you're coming from the english, then I think that the equation should also be "in english" (see next comment), and then what you want to do would work. Can you open a bug for this in bugzilla (and see next comment)? Meanwhile, if you just select the entire inset, and switch it's language with F12, you'll get what you want. This is bug 3011 in bugzilla. See the fix I sent separately... 7, 8 seem to be the same issue as in 6...? Probably. I am not entering them as a separate bug for now. Are these solved with the above-mentioned fix? Is it already in svn? if not, where is the patch? I will check. See http://permalink.gmane.org/gmane.editors.lyx.devel/87817. Let's continue the discussion of this issue in response to that thread.
Re: 20% speedup of paragraph redraw with simple patch
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes: Dov> Hmm, I just came across this yesterday when trying to figure out Dov> what was going on with bug 3011, and wondered about it. I'm not Dov> sure if this is what you mean or not, but it might be relevant... Dov> http://www.lyx.org/trac/browser/lyx-devel/trunk/src/Paragraph.cpp?rev=18599#L446 Yes, what I mean is that in this case we would have to recreate the structure instead of update it. I do not know how costly it is but Abdel is confident that it is not a problem. JMarc
Re: [patch] Language of Inset (bug 3011)
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes: Dov> Attached is the patch using current_font. Is this Okay? The patch is definitely correct. Please apply. Dov> I actually wanted to solve this in a more complete way, by Dov> setting the font to current_font directly within Dov> paragraph::insertInset() if no explicit font is provided; but I Dov> don't have access to real_current_font within Paragraph... Any Dov> thoughts on this? No, Paragraph is not supposed to have access to this font. Dov> Could the versions of insertInset which do not take a font be Dov> made private, so that one would always have to provide a font Dov> explicitly? Yes, I think we should do this (or even check whether these versions are useful at all). JMarc
Spaces in Bidi part #2
Okay, I'm starting a new thread for this issue. This is now bug 3870 in bugzilla (http://bugzilla.lyx.org/show_bug.cgi?id=3870). The problem: typing spaces at RTL/LTR boundaries does not always do what the user expects/wants. (The reason I opened a new bug, is that this really a different issue than what we have solved up until now (bug 3789): that was mainly about getting the GUI and backend to match. Now that they match, we can deal with the "real" issue. The only thing we have done for the "real issue" so far, is that in "normal typing" --- i.e., typing in the logical order --- the language of the space will be set correctly, regardless of whether or not the user switches languages before or after typing the space. We may decide, in the end, that that's not necessary, either...) Note that there are two separate issues: 1) What the end result should look like (at the buffer / latex output level) 2) How we achieve that result, at the same time making the user-experience as simple as possible Note that (1) is totally unrelated to visual/logical movement --- there's no cursor at all in the end result. I'm quite sure that also (2) is orthogonal to the question of visual movement, but I'm not 100% sure... Obviously, (2) can only be solved after (1), because we first need to know what we want to achieve. So I'm focusing on (1) for now: There there are some subtleties to this issue which I'm not sure that everyone appreciates, and which make a solution to this not as trivial as some of you seem to think it should be. The hard part is to make sure that we maintain logical correctness of the resulting text. Logical correctness is important, because if the text is *not* logically correct, then you get "hidden" problems: usually the text looks fine, so the user thinks there's no problem. Bit in certain situations, problems suddenly appear, but by then the user isn't aware of them and doesn't notice. For example: I've been saying all along that the *correct* way is that spaces at RTL/LTR boundaries be in the language (direction, really) of the paragraph. Any other situation is logically incorrect. Attached is a lyx document demonstrating this. (Now is the time to look at the file, there are explanations about it inside it itself. For those of you who don't have hebrew in latex, I'm attaching the dvi, too). I think this demonstrates the necessity of maintaining logical correctness. So now we have to see how we achieve (2). However, we have the following rule: any "magic" has to happen in the GUI; i.e., the LyX buffer should already represent a logically correct situation; i.e., when we generate the latex, we should not have to apply any bidi logic at all --- just make what has *already* been marked as RTL, as RTL, and what's LTR as LTR. So now we can discuss how we go about (2). Hope this clarifies the situation... Dov spaces_at_bidi_boundary.dvi Description: TeX dvi file spaces_at_bidi_boundary.lyx Description: application/lyx
Re: [patch] Language of Inset (bug 3011)
Jean-Marc Lasgouttes wrote: "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes: Dov> Attached is the patch using current_font. Is this Okay? The patch is definitely correct. Please apply. Thanks, committed. Dov> Could the versions of insertInset which do not take a font be Dov> made private, so that one would always have to provide a font Dov> explicitly? Yes, I think we should do this (or even check whether these versions are useful at all). JMarc In that case, it looks like there's only one other place where the form without a font is still used: Paragraph::checkBiblio(bool track_changes) I'm not familiar with this function at all. However, it is only used in one place, so I think that it should also get a font, and then call insertInset with a font. I don't know which font should be used here, though. Also note that this function (checkBiblio) has a big FIXME at the top anyhow... I'll try to send a patch which does all this...
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Dov Feldstern wrote: Miki Dovrat wrote: Are these solved with the above-mentioned fix? Is it already in svn? if not, where is the patch? I will check. See http://permalink.gmane.org/gmane.editors.lyx.devel/87817. Let's continue the discussion of this issue in response to that thread. Sorry, wrong link. Anyhow, this is committed now (r18781).
Re: [patch] Language of Inset (bug 3011)
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes: Dov> In that case, it looks like there's only one other place where Dov> the form without a font is still used: Dov> Paragraph::checkBiblio(bool track_changes) Dov> I'm not familiar with this function at all. However, it is only Dov> used in one place, so I think that it should also get a font, and Dov> then call insertInset with a font. I don't know which font should Dov> be used here, though. Also note that this function (checkBiblio) Dov> has a big FIXME at the top anyhow... OK. I think this should use an explicit font (but it does not need to access current_font. Dov> I'll try to send a patch which does all this... This probably can wait for 1.6, since the real bug is fixed. But you can add this to your personal TODO list :) JMarc
Re: [PATCH-updated] Make HTML Export Work
On Friday 15 June 2007 05:39:01 Richard Heck wrote: > Now seeking an OK to commit. > > Richard Richard has gave this some thought and has tested this thoroughly so I am inclined to give this my OK. Any objection? -- José Abílio
Re: [PATCH-updated] Make HTML Export Work
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Richard> The patch also includes some associated updates to the Richard> documentation. Jean-Marc> But not Extended.lyx. Forget this. This patch does not get rid of originaldir. JMarc
Re: [PATCH-updated] Make HTML Export Work
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> On Friday 15 June 2007 05:39:01 Richard Heck wrote: >> Now seeking an OK to commit. >> >> Richard José> Richard has gave this some thought and has tested this José> thoroughly so I am inclined to give this my OK. Any objection? Since there is no change to the code, the worst that can happen is that HTML export does not work, which was the case already. So I think it is safe. JMarc
Re: [PATCH-updated] Make HTML Export Work
On Fri, Jun 15, 2007 at 12:39:01AM -0400, Richard Heck wrote: > This patch is now slightly updated. In place of the two scripts > tex4html_copy.py and dir_copy.py, there is now just one, ext_copy.py. > Without any optional arguments, this script acts like dir_copy.py did: > It copies all files in LyX's temporary directory to a subdirectory of > the target directory. But now the script takes two optional arguments: > -e: a list of extensions to copy, by default all > -t: an extension to add to the name of the generated target > directory, by default "LyXconv" > The idea with the default in the latter case is simply to avoid > conflicting filenames. But if, like Uwe, you feel like being reckless > ;-), you can do define your HTML copier as: > python ext_copy.py -e html,css,png -t . $$i $$o > and you'll export to /path/to/filename.html/. Note the use of the dot here. > > This new patch will allow easy handling of other converters, such as > hevea (and if anyone knows what kinds of files it generates, let me > know, and I'll add the definition to configure.py). You just have to say > what kinds of files to copy. Of course, in some cases, you may end up > copying more than you really needed to copy, but avoiding this is > complicated and, to my mind, not entirely necessary, as this remains an > exceptional case. > > The patch also includes some associated updates to the documentation. This issue has proven to be difficult, so I think that your solution is the less intrusive and workable one. I think that we should support more actively the converters we look for, i.e., provide a -e switch for latex2html and hevea, but this could be done by others who know the kind of output they generate. > Now seeking an OK to commit. I think you got enough of them. Only a suggestion: Please name the script html_copy.py as this is what it is intended for. If you think that it can be used for a more general purpose, such that ext_copy.py is more correct, then avoid adding .html to the directory it creates. Thanks for having solved this long standing problem. -- Enrico
Re: [PATCH-updated] Make HTML Export Work
> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes: Richard> This new patch will allow easy handling of other converters, Richard> such as hevea (and if anyone knows what kinds of files it Richard> generates, let me know, and I'll add the definition to Richard> configure.py). The documentaton is here: http://hevea.inria.fr/doc/index.html but I am not sure what you want to know. Richard> The patch also includes some associated updates to the Richard> documentation. But not Extended.lyx. JMarc
