LyXWinInstaller and WinXPx64
Stephen Harris wrote: German doesn't have a problem with spaces by default because Programme doesn't have any spaces in it. Therefore C:\programme\lyx or C:\programme\miktex will not have a space in it. Beginning with WindowsXPx64 Microsoft only delivers native OS versions for english and japanese. All other OS language versions are'n native. That means also if you use german menus of Windows, the default is always "C:\program files". Just for information. Btw. LyXWinInstaller and all of the installed programs work fine under WindowsXPx64. A happy new year and regards Uwe
Re: [announce] sixth release of LyXWinInstaller
- Original Message - From: "Bo Peng" <[EMAIL PROTECTED]> To: Cc: Sent: Monday, January 02, 2006 4:41 PM Subject: Re: [announce] sixth release of LyXWinInstaller Dear all, It is confirmed that if the .bst file is in a path without space, the bibliography will be generated correctly, even if lyx is installed under c:\program files\lyx. So, 1. It is safe to install lyx to c:\program files, 2. It is not safe to put .bst files in a path with spaces. .lyx files and all figure files are OK, as well as .bib files. Bo To repeat back what you said in a different way for clarification: It is better to install Miktex in C:\Miktex and/or C:\texmf which usually contains the .bst files. A problem is likely to arise if you install Miktex to C:\program files\miktex and/or c:\program files\texmf Storing the output .lyx file and retrieving it later does not require avoiding using a work directory without spaces. IOW, you can use C:\documents and settings\username\My Documents which has a space, or one can also use a nospace directory, C:\MyDocs or C:\LyX\resources\lyx\work\Mydocs So that working around the .bst problem of path and spaces by using a nospace directory path such as C:\texmf\bibtex\bst does not impact negatively on the Windows traditional use of storing files in C:\Documents and Settings\username\My Documents or C:\~...\...\Application data\LyX\Work for later retrieval. No change needs to be made for My Documents to accomodate using a nospace bst (texmf) directory path. Do I understand you correctly? Apparently, the code that works for bibtex and paths with spaces can't be easily substituted to handle bst (some kind of find/replace). From what I read, TeX ends a filename when a space occurs. It used to be that you could quote, "\path\with a space\" and the space wouldn't cause a problem. But there seems to be a problem with quotemarks, two, getting removed. I tried "\path\"with a space"\" but \ is also used as an escape character which is why it maybe doesn't work as well as a path delimiter as /. Regards, Stephen
Can't compile lyx-1.4cvs with gcc 4.1
This is not something I really expected to work, with gcc 4.1 being a work in progress. Still, if someone is interested, here is what happened: In file included from ../../boost/boost/config.hpp:35, from ../../boost/boost/bind.hpp:23, from ../../src/support/translator.h:16, from ../../src/graphics/GraphicsTypes.h:18, from ../../src/graphics/GraphicsLoader.h:27, from render_graphic.h:17, from render_graphic.C:13: ../../boost/boost/config/compiler/gcc.hpp:92:7: warning: #warning "Unknown compiler version - please run the configure tests and report the results" ../../boost/boost/bind.hpp: In function 'void boost::visit_each(V&, const boost::_bi::value&, int) [with V = boost::signals::detail::bound_objects_visitor, T = const InsetBase*]': ../../boost/boost/bind.hpp:296: instantiated from 'void boost::_bi::list2::accept(V&) const [with V = boost::signals::detail::bound_objects_visitor, A1 = boost::reference_wrapper, A2 = boost::_bi::value]' ../../boost/boost/bind/bind_template.hpp:150: instantiated from 'void boost::_bi::bind_t::accept(V&) const [with V = boost::signals::detail::bound_objects_visitor, R = const Buffer* const, F = boost::_mfi::cmf1, L = boost::_bi::list2, boost::_bi::value >]' ../../boost/boost/bind.hpp:1110: instantiated from 'void boost::visit_each(V&, const boost::_bi::bind_t&, int) [with V = boost::signals::detail::bound_objects_visitor, R = const Buffer* const, F = boost::_mfi::cmf1, L = boost::_bi::list2, boost::_bi::value >]' ../../boost/boost/visit_each.hpp:25: instantiated from 'void boost::visit_each(Visitor&, const T&) [with Visitor = boost::signals::detail::bound_objects_visitor, T = boost::_bi::bind_t, boost::_bi::list2, boost::_bi::value > >]' ../../boost/boost/signals/slot.hpp:121: instantiated from 'boost::slot::slot(const F&) [with F = boost::_bi::bind_t, boost::_bi::list2, boost::_bi::value > >, SlotFunction = boost::function >]' render_graphic.C:44: instantiated from here ../../boost/boost/bind.hpp:1105: error: no matching function for call to 'visit_each(boost::signals::detail::bound_objects_visitor&, const InsetBase* const&, int)' make[4]: *** [render_graphic.lo] Error 1 make[4]: Leaving directory `/usr/src/lyx-devel/src/insets' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/src/lyx-devel/src/insets' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/lyx-devel/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/lyx-devel/src' make: *** [all-recursive] Error 1 Helge Hafting
Re: [announce] sixth release of LyXWinInstaller
Dear all, It is confirmed that if the .bst file is in a path without space, the bibliography will be generated correctly, even if lyx is installed under c:\program files\lyx. So, 1. It is safe to install lyx to c:\program files, 2. It is not safe to put .bst files in a path with spaces. .lyx files and all figure files are OK, as well as .bib files. Bo
Re: Screen update improvements
Angus Leeming a écrit : Abdel wrote: your row signature patch is excellent as it reduces screen flickering significantly (you could the flicking on Windows with qtwin). FYI, without this patch (I have not update my cvs yet), my Qt4 port has zero flickering :-) Right. Because Qt4 double buffers everything. I think this patch is solving here a problem which is in the Qt3 frontend. During my port, I have erased all the calls to the "QWidget::repaint" function and I just have one "update" to the screen. In other word, I let Qt decide when to draw. Also right (and good). But if we regenerate a pixmap a hundred times and Qt displays it only once, then there's some redundancy there, no? Totally, both painting should be minimum. I just wanted to point out that (IMHO) the flickering is not due to the pixmap repaint but more to the screen repaint. But as I said, I am not an expert and I am sure that this patch is necessary. Abdel.
Re: [announce] sixth release of LyXWinInstaller
Stephen Harris wrote: >> Right. And since I install at C:\Program Files\LyX and the bloody thing >> works for me, I'm going to put on my grumpy old man hat and say it's a >> "user error" to try and use a .bst file in a path with spaces. > And to think, just last night it was a party hat. The mood swings of old age and new parenthood, huh? -- Angus
Re: Screen update improvements
Abdel wrote: >> your row signature patch is excellent as it reduces screen flickering >> significantly (you could the flicking on Windows with qtwin). > > FYI, without this patch (I have not update my cvs yet), my Qt4 port has > zero flickering :-) Right. Because Qt4 double buffers everything. > I think this patch is solving here a problem which is in the Qt3 > frontend. During my port, I have erased all the calls to the > "QWidget::repaint" function and I just have one "update" to the screen. > In other word, I let Qt decide when to draw. Also right (and good). But if we regenerate a pixmap a hundred times and Qt displays it only once, then there's some redundancy there, no? -- Angus
Re: Screen update improvements
Michael Gerz a écrit : Martin, your row signature patch is excellent as it reduces screen flickering significantly (you could the flicking on Windows with qtwin). FYI, without this patch (I have not update my cvs yet), my Qt4 port has zero flickering :-) I think this patch is solving here a problem which is in the Qt3 frontend. During my port, I have erased all the calls to the "QWidget::repaint" function and I just have one "update" to the screen. In other word, I let Qt decide when to draw. I think the screen redraw that you see is due to an excessive call to repaint() that are not necessary. IMHO this patch tries to reduce the number of painting on the intermediate pixmap and this is good because, as a side effect it reduces also the number of screen repaint. But I am not an expert so maybe this is just because Qt4 is supposed to be totally double-buffered. Abdel. However, I don't understand why we have to redraw the whole screen in case of selections. Doesn't your nice "always draw current row" patch capture selections? I tried the following modification and couldn't find anything going wrong. Could you please enlighten me? Thanks, Michael Index: rowpainter.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v retrieving revision 1.162 diff -u -r1.162 rowpainter.C --- rowpainter.C1 Jan 2006 23:06:23 - 1.162 +++ rowpainter.C2 Jan 2006 19:47:28 - @@ -826,7 +826,7 @@ for (pit_type pit = vi.p1; pit <= vi.p2; ++pit) { Paragraph const & par = text->getPar(pit); yy += par.ascent(); - paintPar(pi, *bv.text(), pit, 0, yy, select || !vi.singlepar); + paintPar(pi, *bv.text(), pit, 0, yy, /*select ||*/ !vi.singlepar); yy += par.descent(); }
Re: [announce] sixth release of LyXWinInstaller
- Original Message - From: "Angus Leeming" <[EMAIL PROTECTED]> To: Cc: Sent: Monday, January 02, 2006 10:21 AM Subject: Re: [announce] sixth release of LyXWinInstaller Michael Gerz wrote: Bo Peng wrote: The mistake is making C:\Program files the default for LyX and friends. I totally agree. I think it is a good idea to install Lyx to c:\lyx by default. No, the directory must be configurable. On my (German) machine, the appropriate directory is "C:\Programme". There is nothing worse than programs that ignore basic Windows guidelines. This will save us from some troubles, but not all. Most windows users save their files under "...\My Documents" or "... and Settings\Desktop" and will still suffer from this problem. It is quite tricky to move these folders to something like D:\Documents. Indeed. We cannot assume that all Windows users have administrator privileges (in fact they shouldn't). Being unable to use "\My Documents" is like forbidding a *nix user to use $HOME (guess what he will tell you :-)). In other words: We have to support spaces in paths to the maximum extent. Right. And since I install at C:\Program Files\LyX and the bloody thing works for me, I'm going to put on my grumpy old man hat and say it's a "user error" to try and use a .bst file in a path with spaces. Signing off this thread now... -- Angus And to think, just last night it was a party hat. I thought your post was missing the usual reminder that whosoever developer declareth the value of patch, yea verily, let him proceed to make it so, to paraphrase: Free software isn't built on assumptions, it's built on contributions. If you're sufficiently inspired by your convictions to want to do something about it, then I'm sure that the MikTeX people will be more than happy to help you help them.
Re: [announce] sixth release of LyXWinInstaller
- Original Message - From: "Michael Gerz" <[EMAIL PROTECTED]> To: "Bo Peng" <[EMAIL PROTECTED]> Cc: "Stephen Harris" <[EMAIL PROTECTED]>; ; Sent: Monday, January 02, 2006 10:04 AM Subject: Re: [announce] sixth release of LyXWinInstaller Bo Peng wrote: The mistake is making C:\Program files the default for LyX and friends. I totally agree. I think it is a good idea to install Lyx to c:\lyx by default. No, the directory must be configurable. On my (German) machine, the appropriate directory is "C:\Programme". There is nothing worse than programs that ignore basic Windows guidelines. Who said anything about the directory not being configurable. The Default installation directory now reads: C:\program files\lyx That can be manually changed to C:\Lyx I think that the Default should be C:\LyX and the user can run the risk of problems of paths with spaces if he chooses by manually installing elsewhere or C:\program files\lyx German doesn't have a problem with spaces by default because Programme doesn't have any spaces in it. Therefore C:\programme\lyx or C:\programme\miktex will not have a space in it. Why doesn't English have the default of C:\Programs? Is it because C:\program files adheres to basic Windows guidelines? No, certainly not. Just because Word pioneered filenames with spaces doesn't mean that practice should be emulated by other editors, nor does Words ability to do this elevate the filename with spaces capability to a "basic windows guideline". Basic windows guidelines should be adopted according to their ability to make windows and other programs work well together. It is certainly not something Microsoft bought on top of Mt. Sinai to redeem its clutch of customers. I've investigated this issue. I have not been able to find any reason for the adoption of path with spaces to make the Windows OS work better or work better with other programs. I think then that the default install of a path with spaces is not part of basic windows guidelines. It is not a guideline but maybe a standard. Microsoft introduces many proprietary standards to gain market share. I see no reason why LyX, as a member of the Free Source community, should endorse MS standards in order to make LyX run poorly in conjunction with its helper programs. To be a basic windows guideline for LyX, it must help LyX run better on Windows. Using paths with spaces damages LyX's (with helper apps) ability to run well on Windows. Thus it is no basic windows guideline which has any bearing on how LyX should be installed. This will save us from some troubles, but not all. Most windows users save their files under "...\My Documents" or "... and Settings\Desktop" and will still suffer from this problem. It is quite tricky to move these folders to something like D:\Documents. Indeed. We cannot assume that all Windows users have administrator privileges (in fact they shouldn't). Being unable to use "\My Documents" is like forbidding a *nix user to use $HOME (guess what he will tell you :-)). In other words: We have to support spaces in paths to the maximum extent. Michael I haven't tested this. But, I don't think there is a problem with My Documents because there is no problem when the work directory is beneath Application Data. When the path which contains *.bst files has no spaces, there is no problem. That nospace path doesn't get changed because you store the lyx file in C:\this is \a path\ wtih a lot \of spaces or in C:\documents and settings\username\my documents
Re: Screen update improvements
On Mon, Jan 02, 2006 at 08:26:13PM +0100, Michael Gerz wrote: > Martin, > > your row signature patch is excellent as it reduces screen flickering > significantly (you could the flicking on Windows with qtwin). > > However, I don't understand why we have to redraw the whole screen in > case of selections. Doesn't your nice "always draw current row" patch > capture selections? > > I tried the following modification and couldn't find anything going > wrong. Could you please enlighten me? > > Thanks, Michael Yes, it works... apparently because !vi.singlerow implies select, in a way that I haven't been able to figure out. So you don't actually save anything. Still might be wise to delete select from the two places where it occurs together with || vi.singlerow. - Martin pgpILSNxnMmCt.pgp Description: PGP signature
Screen update improvements
Martin, your row signature patch is excellent as it reduces screen flickering significantly (you could the flicking on Windows with qtwin). However, I don't understand why we have to redraw the whole screen in case of selections. Doesn't your nice "always draw current row" patch capture selections? I tried the following modification and couldn't find anything going wrong. Could you please enlighten me? Thanks, Michael Index: rowpainter.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v retrieving revision 1.162 diff -u -r1.162 rowpainter.C --- rowpainter.C1 Jan 2006 23:06:23 - 1.162 +++ rowpainter.C2 Jan 2006 19:47:28 - @@ -826,7 +826,7 @@ for (pit_type pit = vi.p1; pit <= vi.p2; ++pit) { Paragraph const & par = text->getPar(pit); yy += par.ascent(); - paintPar(pi, *bv.text(), pit, 0, yy, select || !vi.singlepar); + paintPar(pi, *bv.text(), pit, 0, yy, /*select ||*/ !vi.singlepar); yy += par.descent(); }
Re: Bugs status
On Mon, Jan 02, 2006 at 06:17:31PM +0200, Martin Vermeer wrote: ... > Actually I would put it differently: you are not supposed to mix > character styles and font attributes :-) > > My idea with charstyles has always been, longer term, to become a > logical replacement for visual font attributes. In XML they represent > "elements"; in LaTeX my idea was, that they would replace the existing > Noun and Emph thingies -- and whatever more the layout writers would > find useful... or with a GUI front-end, even the ordinary users. > > [Note that if the bug reporter would have defined and used an Emph > charstyle instead of the Emph font attribute, things would have worked > for him... perhaps a recommended workaround] > > This did not happen for 1.4, as charstyle was viewed as not quite ready > yet (although apparently it is for _some_ users!), but that is still the > programme for me. When done, you wouldn't ever use raw font attributes > anymore. Bugzilla has a fix which simply disables font attribute editing inside a charstyle inset; see above theory. Problem solved :-) What it means in practice is, that if someone insists on using, say Emph inside a charstyle inset, he should define another charstyle that does Emph, and insert that. That works. Alternatively, split the inset in two and put the emphasized text inbetween. See attached, tested and works. OK to commit? - Martin Index: insetcharstyle.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v retrieving revision 1.39 diff -u -p -r1.39 insetcharstyle.C --- insetcharstyle.C25 Nov 2005 14:40:32 - 1.39 +++ insetcharstyle.C2 Jan 2006 18:59:02 - @@ -249,6 +249,19 @@ bool InsetCharStyle::getStatus(LCursor & case LFUN_BREAKPARAGRAPH: case LFUN_BREAKPARAGRAPHKEEPLAYOUT: case LFUN_BREAKPARAGRAPH_SKIP: + // font attributes also not allowed + case LFUN_DEFAULT: + case LFUN_CODE: + case LFUN_ROMAN: + case LFUN_SANS: + case LFUN_BOLD: + case LFUN_ITAL: + case LFUN_EMPH: + case LFUN_NOUN: + case LFUN_UNDERLINE: + case LFUN_FONT_SIZE: + case LFUN_FREEFONT_APPLY: + case LFUN_FREEFONT_UPDATE: status.enabled(false); return true; pgpFyqSEH5WrX.pgp Description: PGP signature
Re: [announce] sixth release of LyXWinInstaller
Michael Gerz wrote: > Bo Peng wrote: > >>>The mistake is making C:\Program files the default for LyX and >>>friends. >>> >>> >>I totally agree. I think it is a good idea to install Lyx to c:\lyx by >>default. >> >> > No, the directory must be configurable. On my (German) machine, the > appropriate directory is "C:\Programme". There is nothing worse than > programs that ignore basic Windows guidelines. > >>This will save us from some troubles, but not all. Most windows users >>save their files under "...\My Documents" or "... and >>Settings\Desktop" and will still suffer from this problem. It is quite >>tricky to move these folders to something like D:\Documents. >> >> > Indeed. We cannot assume that all Windows users have administrator > privileges (in fact they shouldn't). Being unable to use "\My Documents" > is like forbidding a *nix user to use $HOME (guess what he will tell you > :-)). > > In other words: We have to support spaces in paths to the maximum extent. Right. And since I install at C:\Program Files\LyX and the bloody thing works for me, I'm going to put on my grumpy old man hat and say it's a "user error" to try and use a .bst file in a path with spaces. Signing off this thread now... -- Angus
Re: [announce] sixth release of LyXWinInstaller
Bo Peng wrote: The mistake is making C:\Program files the default for LyX and friends. I totally agree. I think it is a good idea to install Lyx to c:\lyx by default. No, the directory must be configurable. On my (German) machine, the appropriate directory is "C:\Programme". There is nothing worse than programs that ignore basic Windows guidelines. This will save us from some troubles, but not all. Most windows users save their files under "...\My Documents" or "... and Settings\Desktop" and will still suffer from this problem. It is quite tricky to move these folders to something like D:\Documents. Indeed. We cannot assume that all Windows users have administrator privileges (in fact they shouldn't). Being unable to use "\My Documents" is like forbidding a *nix user to use $HOME (guess what he will tell you :-)). In other words: We have to support spaces in paths to the maximum extent. Michael
Re: Bugs status
On Monday 02 January 2006 17:41, Herbert Voss wrote: > uuh, this causes an error! > > \tabular{lr} > Jür & gen > \endtabular You are really a magician, splitting Jürgen in half. ;-) > and don't forget \usepackage[latin9]{inputenc} ... :-) We are very modest, in this case 1 is enough. ;-) > Herbert -- José Abílio
Re: Bugs status
Juergen Spitzmueller wrote: Martin Vermeer wrote: Perhaps this should be called an enhancement request and get its own bug number. perhaps. Now convince HIM to put the #2015-fix in ;-) Which of them? ;-) Lars or Gullik. Jean and Marc have already expressed their principal accordance on bugzilla IIRC. Jür & gen uuh, this causes an error! \tabular{lr} Jür & gen \endtabular and don't forget \usepackage[latin9]{inputenc} ... :-) Herbert
Re: Bugs status
Martin Vermeer wrote: > Perhaps this should be called an enhancement request and get its own bug > number. perhaps. > > Now convince HIM to put the #2015-fix in ;-) > > Which of them? ;-) Lars or Gullik. Jean and Marc have already expressed their principal accordance on bugzilla IIRC. Jür & gen
Re: [announce] sixth release of LyXWinInstaller
Angus Leeming wrote: > > Jean-Marc contacted the real TeX gurus on the tex-k mailing list to ask > for some advice. You can find the full thread in the tex-k archives here: > http://www.tug.org/pipermail/tex-k/2005-April/index.html#1287 > A bit more background: http://sarovar.org/tracker/index.php?func=detail&aid=377&group_id=106&atid=493 This "spaces in filenames" stuff is _very_ difficult (if not impossible) to fix, for reasons see the mentioned references. Georg
Re: Bugs status
On Mon, Jan 02, 2006 at 05:39:52PM +0100, Juergen Spitzmueller wrote: > Martin Vermeer wrote: ... > This sounds very reasonable to me. > Perhaps you could add this explanation to the bug report. IIRC there is also > another bug involved which will be fixed by your #2015-patch. > > I propose to move bug 2019 out of the 1.4.0-radar after 2015 is fixed and > target it to 1.5. If the gui for charstyles is in place, we can still see > what we'll do with this. Perhaps this should be called an enhancement request and get its own bug number. > Now convince HIM to put the #2015-fix in ;-) Which of them? ;-) - Martin pgpqQCMNjnKk0.pgp Description: PGP signature
Re: Bugs status
Martin Vermeer wrote: > Actually I would put it differently: you are not supposed to mix > character styles and font attributes :-) > > My idea with charstyles has always been, longer term, to become a > logical replacement for visual font attributes. In XML they represent > "elements"; in LaTeX my idea was, that they would replace the existing > Noun and Emph thingies -- and whatever more the layout writers would > find useful... or with a GUI front-end, even the ordinary users. [...] > This did not happen for 1.4, as charstyle was viewed as not quite ready > yet (although apparently it is for _some_ users!), but that is still the > programme for me. When done, you wouldn't ever use raw font attributes > anymore. This sounds very reasonable to me. Perhaps you could add this explanation to the bug report. IIRC there is also another bug involved which will be fixed by your #2015-patch. I propose to move bug 2019 out of the 1.4.0-radar after 2015 is fixed and target it to 1.5. If the gui for charstyles is in place, we can still see what we'll do with this. Now convince HIM to put the #2015-fix in ;-) Jürgen
Re: Bugs status
On Mon, Jan 02, 2006 at 03:30:21PM +0200, Martin Vermeer wrote: > On Mon, Jan 02, 2006 at 01:01:46PM +0100, Juergen Spitzmueller wrote: > > Martin Vermeer wrote: > > > Actually I don't dare to touch this stuff. The whole font architecture > > > needs an overhaul/simplification. E.g., there are two different > > > getFonts, one in lyxtext (for display) and one in paragraph (for > > > latexing). > > > > If it is too complicated or risky to fix this stuff now, we could of course > > postpone the fix and tell people to not use font colors for representation > > of > > charstyles (or let LyX just ignore such font color definitions). > > I think the restriction is bearable. > > For now, yes. > > - Martin Actually I would put it differently: you are not supposed to mix character styles and font attributes :-) My idea with charstyles has always been, longer term, to become a logical replacement for visual font attributes. In XML they represent "elements"; in LaTeX my idea was, that they would replace the existing Noun and Emph thingies -- and whatever more the layout writers would find useful... or with a GUI front-end, even the ordinary users. [Note that if the bug reporter would have defined and used an Emph charstyle instead of the Emph font attribute, things would have worked for him... perhaps a recommended workaround] This did not happen for 1.4, as charstyle was viewed as not quite ready yet (although apparently it is for _some_ users!), but that is still the programme for me. When done, you wouldn't ever use raw font attributes anymore. - Martin pgp5dI5bRmRwH.pgp Description: PGP signature
Re: [announce] sixth release of LyXWinInstaller
Bo Peng wrote: >> _TeX_ cannot handle spaces. I suppose that you do not really >> know the difference of TeX, LaTeX, pdfTeX, pdfLaTeX, bibTeX, MiKTeX > > I do not. My understanding is that miktex is another implementation of > latex standard ( if there is such a standard). If miktex aims at > windows platform, I assume that it will do something for the path with > spaces problem. Free software isn't built on assumptions, it's built on contributions. If you're sufficiently irritated by this to want to do something about it, then I'm sure that the MikTeX people will be more than happy to help you help them. Or, perhaps, this thread might help: http://thread.gmane.org/gmane.editors.lyx.devel/43772 Jean-Marc contacted the real TeX gurus on the tex-k mailing list to ask for some advice. You can find the full thread in the tex-k archives here: http://www.tug.org/pipermail/tex-k/2005-April/index.html#1287 -- Angus
Re: [announce] sixth release of LyXWinInstaller
> The mistake is making C:\Program files the default for LyX and > friends. I totally agree. I think it is a good idea to install Lyx to c:\lyx by default. This will save us from some troubles, but not all. Most windows users save their files under "...\My Documents" or "... and Settings\Desktop" and will still suffer from this problem. It is quite tricky to move these folders to something like D:\Documents. Cheers, Bo
Re: [announce] sixth release of LyXWinInstaller
> _TeX_ cannot handle spaces. I suppose that you do not really > know the difference of TeX, LaTeX, pdfTeX, pdfLaTeX, bibTeX, MiKTeX I do not. My understanding is that miktex is another implementation of latex standard ( if there is such a standard). If miktex aims at windows platform, I assume that it will do something for the path with spaces problem. Bo
Toolbar setup
On Mon, Jan 02, 2006 at 11:41:55AM +0100, Abdel wrote: > Helge Hafting a écrit : > >On Fri, Dec 23, 2005 at 04:42:17PM +0100, Jean-Marc Lasgouttes wrote: > >>>"Abdel" == Abdel <[EMAIL PROTECTED]> > >>>writes: > >>Abdel> Jean-Marc Lasgouttes a écrit : > >"Abdel" == Abdel <[EMAIL PROTECTED]> > >writes: > >>Abdel> Oups, I have just discovered the math and table bars right > >>Abdel> clicking on the top toolbar. All I can say is WAHOU !!! :-) > >>Abdel> Sorry for that. > Actually, it is possible to edit ui/default.ui to have these > toolbars appear automatically when needed. > >>Abdel> Very good! This should be the default IMHO. > >> > >>Not everybody appreciates to have toolbars popping up at seemingly > >>random times. What we need is an user interface to set these values. > > > >That'd be nice. In the meantime, what exactly do I do to my > >"default.ui" in order to enable this labor-saving behaviour? > > Under windows, the location would be: > \Resources\LyX\ui\default.ui > > Modify the toolbar section like this: > > Toolbars > "standard" "on,top" > "extra" "on,top" > "table" "table,bottom" > "math" "math,bottom" > "minibuffer" "off,bottom" > End > Thanks a lot! Now, I understand that this won't be the default, but how about sticking a commented-out version of this example in the distributed default.ui? That should be safe even for 1.4.0, it is only documentation this way. And it sure makes life easier for anyone wanting to customize this. Then the nice GUI setup can be made for 1.4.1 or whatever. Helge Hafting
Re: ChkTeX errors dialog almost unusable
Angus Leeming wrote: > When the dialog is open, clicking in the main document resets the position > of both dialog and document to the beginning. I find that I have to use > the dialog to naviagate to an error, close the dialog, fix the problem, > rerun chktex and hope that I can return to the same point relatively > quickly by navigating through all those "errors" I've looked at already > and decided were OK. http://bugzilla.lyx.org/show_bug.cgi?id=2179 Regards, Jürgen
ChkTeX errors dialog almost unusable
When the dialog is open, clicking in the main document resets the position of both dialog and document to the beginning. I find that I have to use the dialog to naviagate to an error, close the dialog, fix the problem, rerun chktex and hope that I can return to the same point relatively quickly by navigating through all those "errors" I've looked at already and decided were OK. -- Angus
Re: Bugs status
On Mon, Jan 02, 2006 at 01:01:46PM +0100, Juergen Spitzmueller wrote: > Martin Vermeer wrote: > > Actually I don't dare to touch this stuff. The whole font architecture > > needs an overhaul/simplification. E.g., there are two different > > getFonts, one in lyxtext (for display) and one in paragraph (for > > latexing). > > If it is too complicated or risky to fix this stuff now, we could of course > postpone the fix and tell people to not use font colors for representation of > charstyles (or let LyX just ignore such font color definitions). > I think the restriction is bearable. For now, yes. - Martin pgppHpoCYvp0Q.pgp Description: PGP signature
Re: [PATCH] Tiny text changes
A Happy New Year to verybody! Lars Gullik Bjønnes wrote: > Michael Gerz <[EMAIL PROTECTED]> > writes: > | How about the first change regarding amsart-seq? > > If it is only a label change then it should not be changed now. If it > OTOH fixes a real problem, then we should fix it now. It fixes a typo in the LaTeX preamble and should go in IMHO. The "Exercise" layout references a non-existing counter without it. Georg
Re: Documentation out of date for 1.4.
Bennett Helm wrote: >> 1. One for the Mac users: where is the "preferences" file to be found? >> Currently I have: > It's at ~/Library/Application Support/LyX/preferences. Thanks, Bennett -- Angus
Re: [announce] sixth release of LyXWinInstaller
Stephen Harris wrote: > Bo > > The Miktex installation doc recommends installing Miktex into paths > and/or directories without spaces. LyX has a history of problems > with paths having spaces some passed on from Miktex. > > http://wiki.lyx.org/pmwiki.php/Windows/LyX136pre > 13 July 2005 > Axel Rasche reported that spaces in the file path caused BibTeX to fail. > The adopted solution copies the BibTeX data base to the temp directory, > mangling its name in the process into something that's both recognizable > to the user and useable by BibTeX. Note that this fix hasn't yet made it > into the official sources. ??? Yes it has. It's in the cvs repositories and will be part of future LyX 1.3.7/1.4.0 releases. -- Angus
Re: Bugs status
Martin Vermeer wrote: > Actually I don't dare to touch this stuff. The whole font architecture > needs an overhaul/simplification. E.g., there are two different > getFonts, one in lyxtext (for display) and one in paragraph (for > latexing). If it is too complicated or risky to fix this stuff now, we could of course postpone the fix and tell people to not use font colors for representation of charstyles (or let LyX just ignore such font color definitions). I think the restriction is bearable. Jürgen
Re: Bugs status
On Mon, Jan 02, 2006 at 10:42:58AM +0100, Juergen Spitzmueller wrote: > Martin Vermeer wrote: > > > I think bug 2019 deserves your special attendance. > > > > Hmmm... perhaps the remark in insetcharstyle.C:draw: > > > > // I don't understand why the above .reduce and .realize aren't > > //needed, or even wanted, here. It just works. -- MV 10.04.2005 > > > > isn't quite true... could you have a look? I'm short on time right now. > > I have already tried to implement those, but that didn't change anything. I > have also tried other things to no avail, so I finally gave up. > I fear I just understand the whole fonts framework to less to fix this bug. > E.g. I just do not understand why, apparently, the color that is used to draw > the charstyle text on screen is also used in output, as is the case in the > bug in question. Aren't on-screen font colors and output font colors clearly > separated? > > Jürgen Actually I don't dare to touch this stuff. The whole font architecture needs an overhaul/simplification. E.g., there are two different getFonts, one in lyxtext (for display) and one in paragraph (for latexing). There should be a clear concept of "underlying font", to which a font is reduced (or not) before drawing/latexing, be it the current layout default font, the "outer font" in nested lists, or the "outer font" outside the current inset. As of now, the concept exists but is sort-of implemented all over the place. Would it be an idea to open a bug targeting 1.5 for this? - Martin pgpIivWBEP7hm.pgp Description: PGP signature
Re: Bugs status
On Monday 02 January 2006 10:15, Martin Vermeer wrote: > That having been said, obviously *some* font attributes should appear > both on-screen and in output. My understanding was that, for LaTeX use, > charstyles were for things like Emph and Noun. They should not use > any coloured representation on-screen, but rather "realistic" fonts. For > XML, I just don't know. XML does not have the concept of colours. :-) You are implying a policy here, so it should be the same not matter what backend is being used... unless I missed the point completely, it happened before. ;-) > - Martin -- José Abílio
Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)
Juergen Spitzmueller wrote: > Jean-Marc Lasgouttes wrote: > > I'm very glad that you found the > > cause, but the fix doesn't look > > right. > > Too bad. Then I am at my witness end. I have tried to enhance my witness a bit this year. Here's how I understand this case: After DEPM, doRecordUndo is finally called, where undo.end is calculated as undo.end = cell.lastpit() - last_pit; cell.lastpit() is the lastpit of the buffer _including_ the paragraph that will be deleted. last_pit is the paragraph where the cursor sits. If this is the first paragraph (pit = 0), then undo.end = cell.lastpit(), which is 1 bigger than lastpit() of the buffer _after_ DEPM. Now if undo is activated after DEPM, textUndoOrRedo calls doRecordUndo again, with a last_pit that is calculated from cell_dit.lastpit() - undo.end. In our case, this is -1, since, as elaborated, undo.end is 1 bigger than current lastpit. Until now, we thought that such a value is invalid, but as I understand it now, this is correct, since last_pit is again only used to calculate undo.end: undo.end = cell.lastpit() - last_pit; which is undo.end = cell.lastpit() - (-1), e.g. undo.end = cell.lastpit() + 1 IMHO this is correct, since the deleted paragraph is being added again at this stage, so undo.end has to increase by one. However, I'm not definitely sure. Let's have a look at the crash. This is due to the first action of doRecordUndo: if (first_pit > last_pit) std::swap(first_pit, last_pit); this is of course triggeres if last_pit = -1, but it shouldn't in this case. I don't know if it crashes because swap cannot handle negative values or because of some later action, anyway, it just shouldn't try to swap the two values here. So my proposal to fix the bug now is - if (first_pit > last_pit) + if (last_pit >= 0 && first_pit > last_pit) std::swap(first_pit, last_pit); (see attached patch). As expected, this fixes the crash and also works as expected for undo after DEPM. Does this sound reasonable? Jürgen Index: undo.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/undo.C,v retrieving revision 1.69 diff -u -r1.69 undo.C --- undo.C 24 Nov 2005 16:22:39 - 1.69 +++ undo.C 2 Jan 2006 11:43:19 - @@ -64,7 +64,9 @@ bool isFullBuffer, limited_stack & stack) { - if (first_pit > last_pit) + // last_pit can legally be -1 when a DEPM action in the first paragraph + // has to be restored! Then undo.end below is cell.lastpit + 1 + if (last_pit >= 0 && first_pit > last_pit) std::swap(first_pit, last_pit); // create the position information of the Undo entry Undo undo; @@ -150,10 +152,9 @@ Buffer * buf = bv.buffer(); DocIterator cell_dit = undo.cell.asDocIterator(&buf->inset()); - doRecordUndo(Undo::ATOMIC, cell_dit, - undo.from, cell_dit.lastpit() - undo.end, bv.cursor(), - undo.bparams, undo.isFullBuffer, - otherstack); + doRecordUndo(Undo::ATOMIC, cell_dit, undo.from, + cell_dit.lastpit() - undo.end, bv.cursor(), + undo.bparams, undo.isFullBuffer, otherstack); // This does the actual undo/redo. //lyxerr << "undo, performing: " << undo << std::endl;
Re: lyx 1.4.0 for windows: compilation progress report and impression
Helge Hafting a écrit : On Fri, Dec 23, 2005 at 04:42:17PM +0100, Jean-Marc Lasgouttes wrote: "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> Jean-Marc Lasgouttes a écrit : "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> Oups, I have just discovered the math and table bars right Abdel> clicking on the top toolbar. All I can say is WAHOU !!! :-) Abdel> Sorry for that. Actually, it is possible to edit ui/default.ui to have these toolbars appear automatically when needed. Abdel> Very good! This should be the default IMHO. Not everybody appreciates to have toolbars popping up at seemingly random times. What we need is an user interface to set these values. That'd be nice. In the meantime, what exactly do I do to my "default.ui" in order to enable this labor-saving behaviour? Under windows, the location would be: \Resources\LyX\ui\default.ui Modify the toolbar section like this: Toolbars "standard" "on,top" "extra" "on,top" "table" "table,bottom" "math" "math,bottom" "minibuffer" "off,bottom" End I copied a default.ui from /usr/share/lyx/ui to .lyx/ui but found no trivial way of enabling automatic toolbars. Attached my default.ui Helge Hafting # -*- text -*- # file default.ui # This file is part of LyX, the document processor. # Licence details can be found in the file COPYING. # author John Levon # Full author contact details are available in file CREDITS. # This is the default LyX user interface definition file. # The syntax should be straightforward enough. # The interface is designed (partially) following the KDE Human Interface # Guidelines (http://usability.kde.org/hig/) Include "stdmenus.ui" Include "stdtoolbars.ui" # Which toolbars to use. # # The second parameter are the flags : # # on: the toolbar is visible # off: the toolbar is not visible # math: the toolbar is visible only when in math # table: the toolbar is visible only when in a table # top: the toolbar should be at the top of the window # bottom: the toolbar should be at the bottom of the window # left: the toolbar should be at the left of the window # right: the toolbar should be at the right of the window # Toolbars "standard" "on,top" "extra" "on,top" "table" "table,bottom" "math" "math,bottom" "minibuffer" "off,bottom" End
Re: Documentation out of date for 1.4.
On Monday 02 January 2006 02:32, Lars Gullik Bjønnes wrote: > > Does it actually say 'voil' or is my mailreader/terminal a bit off? I see "voilà"... So probably some encoding mess from your mailreader. :-) :-) -- José Abílio
Re: Bugs status
On Mon, Jan 02, 2006 at 10:42:58AM +0100, Juergen Spitzmueller wrote: > Martin Vermeer wrote: > > > I think bug 2019 deserves your special attendance. > > > > Hmmm... perhaps the remark in insetcharstyle.C:draw: > > > > // I don't understand why the above .reduce and .realize aren't > > //needed, or even wanted, here. It just works. -- MV 10.04.2005 > > > > isn't quite true... could you have a look? I'm short on time right now. > > I have already tried to implement those, but that didn't change anything. I > have also tried other things to no avail, so I finally gave up. > I fear I just understand the whole fonts framework to less to fix this bug. > E.g. I just do not understand why, apparently, the color that is used to draw > the charstyle text on screen is also used in output, as is the case in the > bug in question. Aren't on-screen font colors and output font colors clearly > separated? As further info, it appears that I have copied the getDrawFont/tmpfont etc. mechanism from insetert. There, however, the ::latex method ouputs directly by brute force, while in charinset, it goes over insettext, and thus lyxtext. Perhaps this is too powerful. That having been said, obviously *some* font attributes should appear both on-screen and in output. My understanding was that, for LaTeX use, charstyles were for things like Emph and Noun. They should not use any coloured representation on-screen, but rather "realistic" fonts. For XML, I just don't know. - Martin pgphyQqFTB0B4.pgp Description: PGP signature
Re: lyx 1.4.0 for windows: compilation progress report and impression
On Fri, Dec 23, 2005 at 04:42:17PM +0100, Jean-Marc Lasgouttes wrote: > > "Abdel" == Abdel <[EMAIL PROTECTED]> writes: > > Abdel> Jean-Marc Lasgouttes a écrit : > >>> "Abdel" == Abdel <[EMAIL PROTECTED]> > >>> writes: > Abdel> Oups, I have just discovered the math and table bars right > Abdel> clicking on the top toolbar. All I can say is WAHOU !!! :-) > Abdel> Sorry for that. > >> Actually, it is possible to edit ui/default.ui to have these > >> toolbars appear automatically when needed. > > Abdel> Very good! This should be the default IMHO. > > Not everybody appreciates to have toolbars popping up at seemingly > random times. What we need is an user interface to set these values. That'd be nice. In the meantime, what exactly do I do to my "default.ui" in order to enable this labor-saving behaviour? I copied a default.ui from /usr/share/lyx/ui to .lyx/ui but found no trivial way of enabling automatic toolbars. Helge Hafting
Re: Bugs status
On Mon, Jan 02, 2006 at 10:42:58AM +0100, Juergen Spitzmueller wrote: > Martin Vermeer wrote: > > > I think bug 2019 deserves your special attendance. > > > > Hmmm... perhaps the remark in insetcharstyle.C:draw: > > > > // I don't understand why the above .reduce and .realize aren't > > //needed, or even wanted, here. It just works. -- MV 10.04.2005 > > > > isn't quite true... could you have a look? I'm short on time right now. > > I have already tried to implement those, but that didn't change anything. I > have also tried other things to no avail, so I finally gave up. > I fear I just understand the whole fonts framework to less to fix this bug. > E.g. I just do not understand why, apparently, the color that is used to draw > the charstyle text on screen is also used in output, as is the case in the > bug in question. Aren't on-screen font colors and output font colors clearly > separated? In my understanding the colour on-screen is the one that was defined in the layout file. What appears in the LaTeX output is defined in the inset's ::latex method. No, I don't think the on-screen colour should appear in the output. If it does, something is wrong. - Martin pgpkcfiCt2K0r.pgp Description: PGP signature
Re: Bugs status
Martin Vermeer wrote: > > I think bug 2019 deserves your special attendance. > > Hmmm... perhaps the remark in insetcharstyle.C:draw: > > // I don't understand why the above .reduce and .realize aren't > //needed, or even wanted, here. It just works. -- MV 10.04.2005 > > isn't quite true... could you have a look? I'm short on time right now. I have already tried to implement those, but that didn't change anything. I have also tried other things to no avail, so I finally gave up. I fear I just understand the whole fonts framework to less to fix this bug. E.g. I just do not understand why, apparently, the color that is used to draw the charstyle text on screen is also used in output, as is the case in the bug in question. Aren't on-screen font colors and output font colors clearly separated? Jürgen
Re: Bugs status
On Mon, Jan 02, 2006 at 09:21:09AM +0100, Juergen Spitzmueller wrote: > Martin Vermeer wrote: > > I believe bug 822 is fixed. > > Is 1561 still major? Was partly fixed by Andre. > > > > Are these (and 2155) the only major bugs left for 1.4.0? > > and 1656. I remember that this can be fixed, but in a way that terminates LyX without an emergency save -- unacceptable. Jean-Marc knows this one. > Cf. the list of open, non-fixedintrunk bugs targeted to 1.4.0: > http://tinyurl.com/7qacq > > I think bug 2019 deserves your special attendance. Hmmm... perhaps the remark in insetcharstyle.C:draw: // I don't understand why the above .reduce and .realize aren't //needed, or even wanted, here. It just works. -- MV 10.04.2005 isn't quite true... could you have a look? I'm short on time right now. > Also, you have a pending > patch in bug 2015 ;-) Yes... but it is pending a policy decision (by Lars?) on whether we use the nature of lyxtext, search in a loop, use std::find and/or factor out the thing into its own routine. > Happy New Year to all, > Jürgen A Happy 2006 to you all! - Martin pgpGhKKLCDVvs.pgp Description: PGP signature
Re: Various change tracking issues
On Mon, Jan 02, 2006 at 01:10:00AM +0100, Jean-Marc Lasgouttes wrote: > | What is this a response to? > > >Your 'let's always repaint the row >with the cursor in it' patch I > >belive. > > Right. My palm is not very good at > quoting messages, sorry. > > JMarc > > -- > Lgb For some reason mutt threads it wrong. Perhaps your Palm isn't good at adding threading info either :-/ - Martin pgpc39NZI6YdV.pgp Description: PGP signature
Re: Bugs status
Martin Vermeer wrote: > I believe bug 822 is fixed. > Is 1561 still major? Was partly fixed by Andre. > > Are these (and 2155) the only major bugs left for 1.4.0? and 1656. Cf. the list of open, non-fixedintrunk bugs targeted to 1.4.0: http://tinyurl.com/7qacq I think bug 2019 deserves your special attendance. Also, you have a pending patch in bug 2015 ;-) Happy New Year to all, Jürgen