Class and style files
I just saw, that LyX has some own special (?) class and style files in lib/tex. This is not a TeX-world-friendly solution and makes supporting these files difficult for the package writers. On the other hand an export to LaTeX file won't run, because it chooses the CTAN package and/or style file instead of the LyX ones (if I'm right here). I would propose to upload these files to CTAN as special LyX files (if needed) or in an own LyX directory CTAN://tex-archive/macros/supported/LyX/. But this implies the ok from the original authors. The advantage for LyX is, that these files are part of every TeX-distribution. Herbert
Re: [PATCH] Fix bibliography layout for CV textclass.
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Jean-Marc The following change was probably forgotten by whoever
Jean-Marc introduced the Bib_Environment tag.
Jean-Marc Georg, is this something layout2layout c/should do?
Jean-Marc I'll commit it, since it is trivial and fixes a regression
Jean-Marc (latex output was \item \bibitem{foo}).
Done.
JMarc
Re: [AUCTeX-devel] preview-latex, dvipng, and LyX
Enrico Forestieri [EMAIL PROTECTED] writes:
sorry if this is not the right list. In this case, please, redirect me
to the right one.
The list is quite correct, though there might be a dvipng-specific
list, too.
As you know, LyX (http://www.lyx.org) uses both the preview-latex
package and dvipng to display snippet previews of LaTeX math
formulas. In order to do so it also relies on the output (stdout) of
dvipng to capture the snippet number and its height and depth.
However, in recent versions of preview-latex and dvipng the output
devised for LyX's sake gets corrupted in the following way:
$ dvipng ...
This is dvipng 1.7 Copyright 2002-2005 Jan-Ake Larsson
[1 (preview-latex version 11.81) depth=6 height=16]
this output confuses the script LyX uses for generating preview
snippets, which, instead, is expecting an output like this:
A lesson is learnt, but the damage is irreversible.
I mean, dvipng and preview.sty have been released in this manner, so
there is no sane around letting LyX detect this string and deal with
it. That's the only way to minimize the impact, even if dvipng get
changed again in the next version to give this information in a
different way. So I am copying the LyX developer list with this mail:
they will have to be a part of damage control.
$ dvipng ...
This is dvipng 1.7 Copyright 2002-2005 Jan-Ake Larsson
[1 depth=6 height=16]
I found that the problem is due to both recent versions of preview-latex
and dvipng. For example, this problem doesn't show up in debian testing
but manifests itself on Windows with MikTeX (where a more recent version
of preview.sty is installed).
Here is the relevant part of the diff between the versions of preview.sty
in debian tetex and in MikTeX:
$ diff -u preview.sty.tetex preview.sty.miktex
...
@@ -83,6 +85,7 @@
\DeclareOption{dvips}{%
[EMAIL PROTECTED]@ne
[EMAIL PROTECTED]
+ \special{!/[EMAIL PROTECTED]([EMAIL PROTECTED])def}
\special{!userdict begin/preview-bop-level 0 def%
/bop-hook{/preview-bop-level dup load dup 0 le{/isls false def%
/vsize 792 def/hsize 612 def}if 1 add store}bind def%
...
and here is the relevant code in the dvipng (version 1.7) special.c source
file causing the problem:
if (strncmp(buffer,!/[EMAIL PROTECTED](,18)==0) {
buffer+=18;
length-=18;
while (length0 buffer[length]!=')')
length--;
if (page_imagep==NULL)
Message(BE_NONQUIET, (preview-latex version %.*s),length,buffer);
return;
}
/* preview-latex' tightpage option */
if (strncmp(buffer,!/[EMAIL PROTECTED],19)==0) {
buffer+=19;
SKIPSPACES(buffer);
if (strncmp(buffer,true,4)==0) {
if (page_imagep==NULL)
Message(BE_NONQUIET, (preview-latex tightpage option detected,\
will use its bounding box));
flags |= PREVIEW_LATEX_TIGHTPAGE;
return;
}
}
if (strncmp(buffer,!userdict,9)==0
strstr(buffer+10,7{currentfile token not{stop}if 65781.76
div)!=NULL)
{
if (page_imagep==NULL ~flags PREVIEW_LATEX_TIGHTPAGE)
Message(BE_NONQUIET, (preview-latex = 0.9.1 tightpage option
detected,\
will use its bounding box));
flags |= PREVIEW_LATEX_TIGHTPAGE;
return;
}
As a solution, it would suffice to replace BE_NONQUIET with
BE_VERBOSE in the code snippet above, such as to not clutter stdout
between [1 and depth=...].
I would like to ask if this acceptable for you, or, in case it is not,
if you can suggest an alternative. In this regard, what it is important
is that nothing goes inside [ ... ] except snippet number and depth
and height information.
A second problem that I noticed is that when a font is missing and
mktexpk (or alike) gets called to generate it, its stdout gets intermixed
with that of dvipng, causing a similar (but worse) confusion.
Is it possible to have the stdout of those helper programs redirected to
stderr?
The latter would actually be useful for preview-latex as well, only
that it would be nice to direct the output completely elsewhere (Emacs
does not capture stderr separately): I often have to run preview-latex
several times when new fonts get generated, because the font
generating output confuses it.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: Class and style files
Herbert Voss wrote: I would propose to upload these files to CTAN as special LyX files (if needed) or in an own LyX directory CTAN://tex-archive/macros/supported/LyX/. But this implies the ok from the original authors. The advantage for LyX is, that these files are part of every TeX-distribution. Also my opinion. There is only one problem: LyX comes with a cv class (cv.cls) but CTAN still has a cv-package that uses a cv.sty so that the same name would lead to confusions. I think we should rename LyX's cv.cls to cvLyX.cls or something similar and upload it to CTAN. regards Uwe
Re: [patch] updated BaKoMa4LyX package - ftp.lyx.org question
Jean-Marc Lasgouttes schrieb: Uwe Hello JMarc, I uploaded a new version of the BaKoMa4LyX Windows Uwe font package to Uwe ftp://ftp.devel.lyx.org/pub/incoming/ Hello Uwe. For some reason I cannot find it. My FTP client doesn't show me the file but tells me that it is there, the upload was also successful. But anyway it seems that ftp.lyx.org has no folder with enough permissions to upload files. ftp://ftp.devel.lyx.org/pub/incoming/ has permissions 2773 but 2777 is needed to be able to read all files. ftp://ftp.lyx.org/incoming/ has permissions 2355. I think we should allow uploads for at least one directory. Could you make it available somewhere (or send it to me privately, if it is not too large)? I uploaded it now to http://fkurth.de/uwest/LyX/BaKoMa4LyX.zip regards Uwe
Re: [patch] updated BaKoMa4LyX package - ftp.lyx.org question
Uwe == Uwe Stöhr [EMAIL PROTECTED] writes: Uwe My FTP client doesn't show me the file but tells me that it is Uwe there, the upload was also successful. Strange I see nothing. Uwe But anyway it seems that ftp.lyx.org has no folder with enough Uwe permissions to upload files. Uwe ftp://ftp.devel.lyx.org/pub/incoming/ has permissions 2773 but Uwe 2777 is needed to be able to read all files. When I login to ftp.devel as lasgouttes, I cannot read into incoming/. Lars, can you change that please? Uwe ftp://ftp.lyx.org/incoming/ has permissions 2355. I think we Uwe should allow uploads for at least one directory. Unfortunately, I did not manage to create the directory correctly (we only have ftp access). Lars, if you cannot get via people to set the right permissions, I will delete the directory. Uwe I uploaded it now to Uwe http://fkurth.de/uwest/LyX/BaKoMa4LyX.zip I got it.
Re: [patch] updated BaKoMa4LyX package - ftp.lyx.org question
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Uwe I uploaded it now to Uwe http://fkurth.de/uwest/LyX/BaKoMa4LyX.zip Jean-Marc I got it. I gorgot the end of my message: shouldn't we add some version number to the file? JMarc
Re: [patch] updated BaKoMa4LyX package
Jean-Marc Lasgouttes wrote: I got it. I forgot the end of my message: shouldn't we add some version number to the file? Yes, you can give it _now_ the version number 1.0 ;-). I also just noticed that ftp://ftp.lyx.org/pub/lyx/contrib/ contains two bakoma4lyx rpm-files. Could somebody please update them too? Is the number -1-2 in their filenames a version number? If yes we should number the new bakoma4lyx package with -1-3 and 1.3 resp. regards uwe
bugzilla permission request
Hello developers, Angus wrote in http://bugzilla.lyx.org/show_bug.cgi?id=2193#c4 that I should have permissions to mark bugs as fixed. Could somebody please give me this permission? thanks and regards Uwe
Re: bugzilla permission request
Uwe == Uwe Stöhr [EMAIL PROTECTED] writes: Uwe Hello developers, Angus wrote in Uwe http://bugzilla.lyx.org/show_bug.cgi?id=2193#c4 that I should Uwe have permissions to mark bugs as fixed. Could somebody please Uwe give me this permission? I did that. JMarc
Re: [AUCTeX-devel] preview-latex, dvipng, and LyX
David Kastrup wrote: However, in recent versions of preview-latex and dvipng the output devised for LyX's sake gets corrupted in the following way: $ dvipng ... This is dvipng 1.7 Copyright 2002-2005 Jan-Ake Larsson [1 (preview-latex version 11.81) depth=6 height=16] this output confuses the script LyX uses for generating preview snippets, which, instead, is expecting an output like this: A lesson is learnt, but the damage is irreversible. I mean, dvipng and preview.sty have been released in this manner, so there is no sane around letting LyX detect this string and deal with it. That's the only way to minimize the impact, even if dvipng get changed again in the next version to give this information in a different way. So I am copying the LyX developer list with this mail: they will have to be a part of damage control. Hi, David! Damage control from this side is easy: no version of LyX has been released that uses dvipng. (That will be part of the upcoming 1.4.0 release.) That means we can jump through whatever hoops you choose to present us with ;-) The obvious solution is to add a flag to dvipng --LyX that is used to swap the existing BE_NONQUIET for BE_VERBOSE A second problem that I noticed is that when a font is missing and mktexpk (or alike) gets called to generate it, its stdout gets intermixed with that of dvipng, causing a similar (but worse) confusion. Is it possible to have the stdout of those helper programs redirected to stderr? The latter would actually be useful for preview-latex as well, only that it would be nice to direct the output completely elsewhere (Emacs does not capture stderr separately): I often have to run preview-latex several times when new fonts get generated, because the font generating output confuses it. Perhaps one reasonable solution would be to add a flag to dvipng --redirect_externals_stdout_to_stderr Or somesuch ;-) -- Angus
Re: Crash running spellcheck
My apologies if this is a duplicate, the previous copy went to an individual instead of the list, which I'm not a subscriber of. I had the same problem after doing 'make install', so the problem is not from running src/lyx. - bernard On 1/5/06, Algernon [EMAIL PROTECTED] wrote: On 1/5/06, Jean-Marc Lasgouttes [EMAIL PROTECTED] wrote: snip It would be nice if you could tell us what spellchecker is in used (output of lyx -version would be fine) and give a precise recipe for the crash. JMarc Thank you for nudging me. I have not done a 'make install' yet, I'm running from src/lyx. The output is below: [EMAIL PROTECTED] ~/Packages/OfficeSuites/Lyx/lyx-1.4.0pre3]$ src/lyx --version LyX 1.4.0pre3 of Thu, Jan 30, 2003 Built on Jan 5 2006, 00:44:13 Configuration Host type: i686-pc-linux-gnu Special build flags:compression assertions warnings use-aspell use-ispell C Compiler: gcc C Compiler LyX flags: C Compiler flags: -W -Wall -O2 C++ Compiler: g++ (3.3.1) C++ Compiler LyX flags: -fno-exceptions C++ Compiler flags: -W -Wall -O2 Linker flags: Linker user flags: Qt Frontend: Qt version: 3.3.5 Packaging: posix LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx [EMAIL PROTECTED] ~/Packages/OfficeSuites/Lyx/lyx-1.4.0pre3]$ The spellchecker used is aspell-0.60.4, with the aspell6-en-6.0-0 dictionary. Here is a link to a series of screenshots showing exactly the steps that caused the error: http://home.speedfactory.net/algernon/LyX_errors/Steps%20Leading%20to%20LyX%20error%202005-01-05.html Info concerning supporting packages: I'm using LFS, kernel 2.4.22 - I've compiled everything myself. Results of various 'make check's and tests: qt-x11-free-3.3.5 - ran demo suite with no problems (except initial placement of window was off center). ImageMagick-6.2.5 - All 714 tests behaved as expected (33 expected failures) - All tests successful. chktex - 'make check' reports OK! If I ran any other tests, they should have been fine, because I noted no discrepancies. The window manager is sWM (small window manager). Please let me know if I can supply any other helpful information. - bernard
Bug 2015 patch + profiling
Attached the IMHO current best version of this patch, which was held
up by a discussion about the best way to find the pit value of a given
paragraph (loop, linear computation for vector, or some std::find
thing). This proposal doesn't assume vector.
I did a bit of profiling on this. The file (test 1) is found at
www.hut.fi/~mvermeer/p.txt
Test file (1) was created by typing into the end of the User Guide.
Total time 107 seconds. Couple of paragraphs typed.
Test file (2) was created by typing into LyX at the start of the User guide
for some seconds, filling half a screen. There was no feeling of
slowness compared to pre-patch. Total time was 120 s.
Test file (3) was typing a screenful into an empty document. Total time
41 s.
Result:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls ms/call ms/call name
Test 1 (End User Guide):
0.09 77.58 0.1019905 0.01 0.01
LyXText::getFont(Paragraph const, int) const
Test 2 (Start User Guide):
0.10 87.18 0.1237263 0.00 0.00
LyXText::getFont(Paragraph const, int) const
Test 3 (Empty Doc):
0.40 12.48 0.1729358 0.01 0.01
LyXText::getFont(Paragraph const, int) const
So it seems that even with the patch, no more than fractions of seconds
are spent in LyXText::getFont. I think we can live with that. And most
importantly: even at the end of the user guide, with lots of paragraphs
in the document above it, we see no slowing down.
Is it OK to check this in?
- Martin
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.636
diff -u -p -r1.636 text2.C
--- text2.C 6 Dec 2005 14:54:23 - 1.636
+++ text2.C 6 Jan 2006 17:06:36 -
@@ -191,6 +191,19 @@ LyXFont LyXText::getFont(Paragraph const
if (!isMainText())
applyOuterFont(font);
+ // Find the pit value belonging to paragraph. This will not break
+ // even if pars_ would not be a vector anymore.
+ // Performance appears acceptable.
+ pit_type pit = pars_.size();
+ for (pit_type it = 0; it pit; ++it)
+ if (pars_[it] == par) {
+ pit = it;
+ break;
+ }
+ // Realize against environment font information
+ if (pit pars_.size())
+ font.realize(outerFont(pit, pars_));
+
// Realize with the fonts of lesser depth.
font.realize(defaultfont_);
pgpQOPwY1VthU.pgp
Description: PGP signature
Re: LyX 1.3.7pre6 question
Angus Leeming wrote: I can't find the file exdll.h in CVS, where is it? C:\Program Files\NSIS\Contrib\ExDLL\exdll.h This file isn't part of NSIS 2.10, 2.11, and 2.12 (I don't have prior versions). But it is in NSIS' CVS: http://cvs.sourceforge.net/viewcvs.py/nsis/NSIS/Contrib/ExDLL/ I'd rather have a pointer to the file in the lyx_configure.C blurb. Could you ask on the NSIS forum why it was removed? (If it was removed...) The answer: The ExDLL.h is a source code file and now no longer part of the standard installation. It can be found in the NSIS' source code package. We should add this location to the lyx_configure.C blurb: http://cvs.sourceforge.net/viewcvs.py/nsis/NSIS/Contrib/ExDLL/ regards Uwe
Re: LyX 1.3.7pre6 question
Uwe Stöhr wrote: We should add this location to the lyx_configure.C blurb: http://cvs.sourceforge.net/viewcvs.py/nsis/NSIS/Contrib/ExDLL/ Done. Thanks, Uwe. Angus
Bug in backspace/delete on para boundary
Anyone else see this problem? Position the cursor on a paragraph
boundary, i.e. beginning of paragraph, and press backspace. Or end of
paragraph, and press delete. The paragraphs below the merged ones are
not properly repainted.
The attached patch fixes this.
- Martin
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.323
diff -u -p -r1.323 text3.C
--- text3.C 31 Dec 2005 11:40:32 - 1.323
+++ text3.C 6 Jan 2006 17:20:08 -
@@ -621,6 +621,9 @@ void LyXText::dispatch(LCursor cur, Fu
case LFUN_DELETE:
if (!cur.selection()) {
+ if (cur.pos() == cur.paragraph().size())
+ // Par boundary, force full-screen update
+ singleParUpdate = false;
needsUpdate = Delete(cur);
cur.resetAnchor();
// It is possible to make it a lot faster still
@@ -649,6 +652,9 @@ void LyXText::dispatch(LCursor cur, Fu
case LFUN_BACKSPACE:
if (!cur.selection()) {
if
(bv-owner()-getIntl().getTransManager().backspace()) {
+ // Par boundary, full-screen update
+ if (cur.pos() == 0)
+ singleParUpdate = false;
needsUpdate = backspace(cur);
cur.resetAnchor();
// It is possible to make it a lot faster still
pgpSEcpEas9Gj.pgp
Description: PGP signature
[patch] check for preview
I've a trivial patch for chkcongig.ltx to check for theLaTeX-package
preview. I think this should go in because LyX needs it for instant
preview. (The check has the advantage that MiKTeX installs the package
automatically when LyX ist configured.)
regards Uwe
--- chkconfig_old.ltx Sun Jul 17 14:38:54 2005
+++ chkconfig.ltx Sat Jan 07 02:30:40 2006
@@ -214,6 +214,7 @@
\TestPackage{varioref}
\TestPackage{prettyref}
\TestPackage{natbib}
+\TestPackage{preview}
% The test for the graphics package is slightly more involved...
\newcommand\groption{dvips}
Problems trying to implement preview selection.
I thought that it would be very useful to be able to select a piece of text and view the DVI output for (only) that selection. I thought that I might be able to implement it simply by adding the following line to my bind file: \bind F11 copy buffer-new paste buffer-view buffer-close However I came across some problems. Does anyone know how I can overcome them? 1. The bind file does not seem to support multiple commands attached to a single function key. I could use LyX-Server, but is there some way I can make this less inconvenient? 2. Next, buffer-view fails with the Error Cannot export file No information for exporting to I am not sure what this means. Cntl-d works just fine. The documentation for buffer-view appears to be out-of-date. E.g. it claims that buffer-view is in the File menu, but it has been in the view menu for as long as I can remember. 3. When I do a buffer-close, I return to the first buffer rather than the buffer than was open when I did the buffer-new. IMHO buffer-new followed by buffer-close should not change the current buffer. 4. buffer-close prompts me whether I want to discard changes, even if I use undo first so that technically no change has been made. BTW, Reference.lyx does not seem to be available through the help menu. Why is this? if Reference.lyx does not deserve a whole menu item, perhaps we could have a new menuitem Other docs which includes Reference.lyx as a child document. -- John C. McCabe-Dansted Masters Student
Class and style files
I just saw, that LyX has some own special (?) class and style files in lib/tex. This is not a TeX-world-friendly solution and makes supporting these files difficult for the package writers. On the other hand an export to LaTeX file won't run, because it chooses the CTAN package and/or style file instead of the LyX ones (if I'm right here). I would propose to upload these files to CTAN as special LyX files (if needed) or in an own LyX directory CTAN://tex-archive/macros/supported/LyX/. But this implies the ok from the original authors. The advantage for LyX is, that these files are part of every TeX-distribution. Herbert
Re: [PATCH] Fix bibliography layout for CV textclass.
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> The following change was probably forgotten by whoever
Jean-Marc> introduced the Bib_Environment tag.
Jean-Marc> Georg, is this something layout2layout c/should do?
Jean-Marc> I'll commit it, since it is trivial and fixes a regression
Jean-Marc> (latex output was "\item \bibitem{foo}").
Done.
JMarc
Re: [AUCTeX-devel] preview-latex, dvipng, and LyX
Enrico Forestieri <[EMAIL PROTECTED]> writes:
> sorry if this is not the right list. In this case, please, redirect me
> to the right one.
The list is quite correct, though there might be a dvipng-specific
list, too.
> As you know, LyX (http://www.lyx.org) uses both the preview-latex
> package and dvipng to display snippet previews of LaTeX math
> formulas. In order to do so it also relies on the output (stdout) of
> dvipng to capture the snippet number and its height and depth.
>
> However, in recent versions of preview-latex and dvipng the output
> devised for LyX's sake gets corrupted in the following way:
>
> $ dvipng ...
> This is dvipng 1.7 Copyright 2002-2005 Jan-Ake Larsson
> [1 (preview-latex version 11.81) depth=6 height=16]
>
> this output confuses the script LyX uses for generating preview
> snippets, which, instead, is expecting an output like this:
A lesson is learnt, but the damage is irreversible.
I mean, dvipng and preview.sty have been released in this manner, so
there is no sane around letting LyX detect this string and deal with
it. That's the only way to minimize the impact, even if dvipng get
changed again in the next version to give this information in a
different way. So I am copying the LyX developer list with this mail:
they will have to be a part of damage control.
> $ dvipng ...
> This is dvipng 1.7 Copyright 2002-2005 Jan-Ake Larsson
> [1 depth=6 height=16]
>
> I found that the problem is due to both recent versions of preview-latex
> and dvipng. For example, this problem doesn't show up in debian testing
> but manifests itself on Windows with MikTeX (where a more recent version
> of preview.sty is installed).
>
> Here is the relevant part of the diff between the versions of preview.sty
> in debian tetex and in MikTeX:
>
> $ diff -u preview.sty.tetex preview.sty.miktex
> ...
> @@ -83,6 +85,7 @@
> \DeclareOption{dvips}{%
>[EMAIL PROTECTED]@ne
>[EMAIL PROTECTED]
> + \special{!/[EMAIL PROTECTED]([EMAIL PROTECTED])def}
>\special{!userdict begin/preview-bop-level 0 def%
>/bop-hook{/preview-bop-level dup load dup 0 le{/isls false def%
>/vsize 792 def/hsize 612 def}if 1 add store}bind def%
> ...
>
>
> and here is the relevant code in the dvipng (version 1.7) special.c source
> file causing the problem:
>
>
> if (strncmp(buffer,"!/[EMAIL PROTECTED](",18)==0) {
> buffer+=18;
> length-=18;
> while (length>0 && buffer[length]!=')')
> length--;
> if (page_imagep==NULL)
> Message(BE_NONQUIET," (preview-latex version %.*s)",length,buffer);
> return;
> }
>
> /* preview-latex' tightpage option */
> if (strncmp(buffer,"!/[EMAIL PROTECTED]",19)==0) {
> buffer+=19;
> SKIPSPACES(buffer);
> if (strncmp(buffer,"true",4)==0) {
> if (page_imagep==NULL)
> Message(BE_NONQUIET," (preview-latex tightpage option detected,\
> will use its bounding box)");
> flags |= PREVIEW_LATEX_TIGHTPAGE;
> return;
> }
> }
> if (strncmp(buffer,"!userdict",9)==0
> && strstr(buffer+10,"7{currentfile token not{stop}if 65781.76
> div")!=NULL)
> {
> if (page_imagep==NULL && ~flags & PREVIEW_LATEX_TIGHTPAGE)
> Message(BE_NONQUIET," (preview-latex <= 0.9.1 tightpage option
> detected,\
> will use its bounding box)");
> flags |= PREVIEW_LATEX_TIGHTPAGE;
> return;
> }
>
>
> As a solution, it would suffice to replace BE_NONQUIET with
> BE_VERBOSE in the code snippet above, such as to not clutter stdout
> between "[1 " and "depth=...]".
>
> I would like to ask if this acceptable for you, or, in case it is not,
> if you can suggest an alternative. In this regard, what it is important
> is that nothing goes inside "[" ... "]" except snippet number and depth
> and height information.
>
> A second problem that I noticed is that when a font is missing and
> mktexpk (or alike) gets called to generate it, its stdout gets intermixed
> with that of dvipng, causing a similar (but worse) confusion.
>
> Is it possible to have the stdout of those helper programs redirected to
> stderr?
The latter would actually be useful for preview-latex as well, only
that it would be nice to direct the output completely elsewhere (Emacs
does not capture stderr separately): I often have to run preview-latex
several times when new fonts get generated, because the font
generating output confuses it.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: Class and style files
Herbert Voss wrote: I would propose to upload these files to CTAN as special LyX files (if needed) or in an own LyX directory CTAN://tex-archive/macros/supported/LyX/. But this implies the ok from the original authors. The advantage for LyX is, that these files are part of every TeX-distribution. Also my opinion. There is only one problem: LyX comes with a "cv" class (cv.cls) but CTAN still has a "cv"-package that uses a cv.sty so that the same name would lead to confusions. I think we should rename LyX's cv.cls to cvLyX.cls or something similar and upload it to CTAN. regards Uwe
Re: [patch] updated BaKoMa4LyX package - ftp.lyx.org question
Jean-Marc Lasgouttes schrieb: Uwe> Hello JMarc, I uploaded a new version of the BaKoMa4LyX Windows Uwe> font package to Uwe> ftp://ftp.devel.lyx.org/pub/incoming/ Hello Uwe. For some reason I cannot find it. My FTP client doesn't show me the file but tells me that it is there, the upload was also successful. But anyway it seems that ftp.lyx.org has no folder with enough permissions to upload files. ftp://ftp.devel.lyx.org/pub/incoming/ has permissions "2773" but "2777" is needed to be able to read all files. ftp://ftp.lyx.org/incoming/ has permissions "2355". I think we should allow uploads for at least one directory. Could you make it available somewhere (or send it to me privately, if > it is not too large)? I uploaded it now to http://fkurth.de/uwest/LyX/BaKoMa4LyX.zip regards Uwe
Re: [patch] updated BaKoMa4LyX package - ftp.lyx.org question
> "Uwe" == Uwe Stöhr <[EMAIL PROTECTED]> writes: Uwe> My FTP client doesn't show me the file but tells me that it is Uwe> there, the upload was also successful. Strange I see nothing. Uwe> But anyway it seems that ftp.lyx.org has no folder with enough Uwe> permissions to upload files. Uwe> ftp://ftp.devel.lyx.org/pub/incoming/ has permissions "2773" but Uwe> "2777" is needed to be able to read all files. When I login to ftp.devel as lasgouttes, I cannot read into incoming/. Lars, can you change that please? Uwe> ftp://ftp.lyx.org/incoming/ has permissions "2355". I think we Uwe> should allow uploads for at least one directory. Unfortunately, I did not manage to create the directory correctly (we only have ftp access). Lars, if you cannot get via people to set the right permissions, I will delete the directory. Uwe> I uploaded it now to Uwe> http://fkurth.de/uwest/LyX/BaKoMa4LyX.zip I got it.
Re: [patch] updated BaKoMa4LyX package - ftp.lyx.org question
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Uwe> I uploaded it now to Uwe> http://fkurth.de/uwest/LyX/BaKoMa4LyX.zip Jean-Marc> I got it. I gorgot the end of my message: shouldn't we add some version number to the file? JMarc
Re: [patch] updated BaKoMa4LyX package
Jean-Marc Lasgouttes wrote: I got it. I forgot the end of my message: shouldn't we add some version number to the file? Yes, you can give it _now_ the version number "1.0" ;-). I also just noticed that ftp://ftp.lyx.org/pub/lyx/contrib/ contains two bakoma4lyx rpm-files. Could somebody please update them too? Is the number "-1-2" in their filenames a version number? If yes we should number the new bakoma4lyx package with "-1-3" and 1.3 resp. regards uwe
bugzilla permission request
Hello developers, Angus wrote in http://bugzilla.lyx.org/show_bug.cgi?id=2193#c4 that I should have permissions to mark bugs as fixed. Could somebody please give me this permission? thanks and regards Uwe
Re: bugzilla permission request
> "Uwe" == Uwe Stöhr <[EMAIL PROTECTED]> writes: Uwe> Hello developers, Angus wrote in Uwe> http://bugzilla.lyx.org/show_bug.cgi?id=2193#c4 that I should Uwe> have permissions to mark bugs as fixed. Could somebody please Uwe> give me this permission? I did that. JMarc
Re: [AUCTeX-devel] preview-latex, dvipng, and LyX
David Kastrup wrote: >> However, in recent versions of preview-latex and dvipng the output >> devised for LyX's sake gets corrupted in the following way: >> >> $ dvipng ... >> This is dvipng 1.7 Copyright 2002-2005 Jan-Ake Larsson >> [1 (preview-latex version 11.81) depth=6 height=16] >> >> this output confuses the script LyX uses for generating preview >> snippets, which, instead, is expecting an output like this: > > A lesson is learnt, but the damage is irreversible. > > I mean, dvipng and preview.sty have been released in this manner, so > there is no sane around letting LyX detect this string and deal with > it. That's the only way to minimize the impact, even if dvipng get > changed again in the next version to give this information in a > different way. So I am copying the LyX developer list with this mail: > they will have to be a part of damage control. Hi, David! Damage control from this side is easy: no version of LyX has been released that uses dvipng. (That will be part of the upcoming 1.4.0 release.) That means we can jump through whatever hoops you choose to present us with ;-) The obvious solution is to add a flag to dvipng --LyX that is used to swap the existing BE_NONQUIET for BE_VERBOSE >> A second problem that I noticed is that when a font is missing and >> mktexpk (or alike) gets called to generate it, its stdout gets >> intermixed with that of dvipng, causing a similar (but worse) confusion. >> >> Is it possible to have the stdout of those helper programs redirected to >> stderr? > > The latter would actually be useful for preview-latex as well, only > that it would be nice to direct the output completely elsewhere (Emacs > does not capture stderr separately): I often have to run preview-latex > several times when new fonts get generated, because the font > generating output confuses it. Perhaps one reasonable solution would be to add a flag to dvipng --redirect_externals_stdout_to_stderr Or somesuch ;-) -- Angus
Re: Crash running spellcheck
My apologies if this is a duplicate, the previous copy went to an individual instead of the list, which I'm not a subscriber of. I had the same problem after doing 'make install', so the problem is not from running src/lyx. - bernard On 1/5/06, Algernon <[EMAIL PROTECTED]> wrote: > On 1/5/06, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > > It would be nice if you could tell us what spellchecker is in used > > (output of "lyx -version" would be fine) and give a precise recipe for > > the crash. > > > > JMarc > > > > Thank you for nudging me. I have not done a 'make install' yet, I'm > running from src/lyx. The output is below: > > > [EMAIL PROTECTED] ~/Packages/OfficeSuites/Lyx/lyx-1.4.0pre3]$ src/lyx > --version > LyX 1.4.0pre3 of Thu, Jan 30, 2003 > Built on Jan 5 2006, 00:44:13 > Configuration > Host type: i686-pc-linux-gnu > Special build flags:compression assertions warnings > use-aspell use-ispell > C Compiler: gcc > C Compiler LyX flags: > C Compiler flags: -W -Wall -O2 > C++ Compiler: g++ (3.3.1) > C++ Compiler LyX flags: -fno-exceptions > C++ Compiler flags: -W -Wall -O2 > Linker flags: > Linker user flags: > Qt Frontend: > Qt version: 3.3.5 > Packaging: posix > LyX binary dir: /usr/local/bin > LyX files dir: /usr/local/share/lyx > > [EMAIL PROTECTED] ~/Packages/OfficeSuites/Lyx/lyx-1.4.0pre3]$ > > > The spellchecker used is aspell-0.60.4, with the aspell6-en-6.0-0 dictionary. > > Here is a link to a series of screenshots showing exactly the steps > that caused the error: > > http://home.speedfactory.net/algernon/LyX_errors/Steps%20Leading%20to%20LyX%20error%202005-01-05.html > > > Info concerning supporting packages: > > I'm using LFS, kernel 2.4.22 - I've compiled everything myself. > > Results of various 'make check's and tests: > > qt-x11-free-3.3.5 - ran demo suite with no problems (except initial > placement of window was off center). > > ImageMagick-6.2.5 - "All 714 tests behaved as expected (33 expected > failures)" - All tests successful. > > chktex - 'make check' reports ">>> OK!" > > If I ran any other tests, they should have been fine, because I noted > no discrepancies. > > The window manager is sWM (small window manager). > > Please let me know if I can supply any other helpful information. > > - bernard >
Bug 2015 patch + profiling
Attached the IMHO "current best" version of this patch, which was held
up by a discussion about the best way to find the pit value of a given
paragraph (loop, linear computation for , or some std::find
thing). This proposal doesn't assume .
I did a bit of profiling on this. The file (test 1) is found at
www.hut.fi/~mvermeer/p.txt
Test file (1) was created by typing into the end of the User Guide.
Total time 107 seconds. Couple of paragraphs typed.
Test file (2) was created by typing into LyX at the start of the User guide
for some seconds, filling half a screen. There was no feeling of
slowness compared to pre-patch. Total time was 120 s.
Test file (3) was typing a screenful into an empty document. Total time
41 s.
Result:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls ms/call ms/call name
Test 1 (End User Guide):
0.09 77.58 0.1019905 0.01 0.01
LyXText::getFont(Paragraph const&, int) const
Test 2 (Start User Guide):
0.10 87.18 0.1237263 0.00 0.00
LyXText::getFont(Paragraph const&, int) const
Test 3 (Empty Doc):
0.40 12.48 0.1729358 0.01 0.01
LyXText::getFont(Paragraph const&, int) const
So it seems that even with the patch, no more than fractions of seconds
are spent in LyXText::getFont. I think we can live with that. And most
importantly: even at the end of the user guide, with lots of paragraphs
in the document above it, we see no slowing down.
Is it OK to check this in?
- Martin
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.636
diff -u -p -r1.636 text2.C
--- text2.C 6 Dec 2005 14:54:23 - 1.636
+++ text2.C 6 Jan 2006 17:06:36 -
@@ -191,6 +191,19 @@ LyXFont LyXText::getFont(Paragraph const
if (!isMainText())
applyOuterFont(font);
+ // Find the pit value belonging to paragraph. This will not break
+ // even if pars_ would not be a vector anymore.
+ // Performance appears acceptable.
+ pit_type pit = pars_.size();
+ for (pit_type it = 0; it < pit; ++it)
+ if (_[it] == ) {
+ pit = it;
+ break;
+ }
+ // Realize against environment font information
+ if (pit < pars_.size())
+ font.realize(outerFont(pit, pars_));
+
// Realize with the fonts of lesser depth.
font.realize(defaultfont_);
pgpQOPwY1VthU.pgp
Description: PGP signature
Re: LyX 1.3.7pre6 question
Angus Leeming wrote: I can't find the file "exdll.h" in CVS, where is it? C:\Program Files\NSIS\Contrib\ExDLL\exdll.h This file isn't part of NSIS 2.10, 2.11, and 2.12 (I don't have prior versions). But it is in NSIS' CVS: http://cvs.sourceforge.net/viewcvs.py/nsis/NSIS/Contrib/ExDLL/ I'd rather have a pointer to the file in the lyx_configure.C blurb. Could you ask on the NSIS forum why it was removed? (If it was removed...) The answer: The ExDLL.h is a source code file and now no longer part of the standard installation. It can be found in the NSIS' source code package. We should add this location to the lyx_configure.C blurb: http://cvs.sourceforge.net/viewcvs.py/nsis/NSIS/Contrib/ExDLL/ regards Uwe
Re: LyX 1.3.7pre6 question
Uwe Stöhr wrote: We should add this location to the lyx_configure.C blurb: http://cvs.sourceforge.net/viewcvs.py/nsis/NSIS/Contrib/ExDLL/ Done. Thanks, Uwe. Angus
Bug in backspace/delete on para boundary
Anyone else see this problem? Position the cursor on a paragraph
boundary, i.e. beginning of paragraph, and press backspace. Or end of
paragraph, and press delete. The paragraphs below the merged ones are
not properly repainted.
The attached patch fixes this.
- Martin
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.323
diff -u -p -r1.323 text3.C
--- text3.C 31 Dec 2005 11:40:32 - 1.323
+++ text3.C 6 Jan 2006 17:20:08 -
@@ -621,6 +621,9 @@ void LyXText::dispatch(LCursor & cur, Fu
case LFUN_DELETE:
if (!cur.selection()) {
+ if (cur.pos() == cur.paragraph().size())
+ // Par boundary, force full-screen update
+ singleParUpdate = false;
needsUpdate = Delete(cur);
cur.resetAnchor();
// It is possible to make it a lot faster still
@@ -649,6 +652,9 @@ void LyXText::dispatch(LCursor & cur, Fu
case LFUN_BACKSPACE:
if (!cur.selection()) {
if
(bv->owner()->getIntl().getTransManager().backspace()) {
+ // Par boundary, full-screen update
+ if (cur.pos() == 0)
+ singleParUpdate = false;
needsUpdate = backspace(cur);
cur.resetAnchor();
// It is possible to make it a lot faster still
pgpSEcpEas9Gj.pgp
Description: PGP signature
[patch] check for preview
I've a trivial patch for chkcongig.ltx to check for theLaTeX-package
"preview". I think this should go in because LyX needs it for instant
preview. (The check has the advantage that MiKTeX installs the package
automatically when LyX ist configured.)
regards Uwe
--- chkconfig_old.ltx Sun Jul 17 14:38:54 2005
+++ chkconfig.ltx Sat Jan 07 02:30:40 2006
@@ -214,6 +214,7 @@
\TestPackage{varioref}
\TestPackage{prettyref}
\TestPackage{natbib}
+\TestPackage{preview}
% The test for the graphics package is slightly more involved...
\newcommand\groption{dvips}
Problems trying to implement "preview selection".
I thought that it would be very useful to be able to select a piece of text and view the DVI output for (only) that selection. I thought that I might be able to implement it simply by adding the following line to my bind file: \bind "F11" "copy" "buffer-new" "paste" "buffer-view" "buffer-close" However I came across some problems. Does anyone know how I can overcome them? 1. The bind file does not seem to support multiple commands attached to a single function key. I could use LyX-Server, but is there some way I can make this less inconvenient? 2. Next, buffer-view fails with the Error "Cannot export file No information for exporting to" I am not sure what this means. Cntl-d works just fine. The documentation for buffer-view appears to be out-of-date. E.g. it claims that "buffer-view" is in the File menu, but it has been in the view menu for as long as I can remember. 3. When I do a buffer-close, I return to the first buffer rather than the buffer than was open when I did the "buffer-new". IMHO "buffer-new" followed by "buffer-close" should not change the current buffer. 4. "buffer-close" prompts me whether I want to discard changes, even if I use "undo" first so that technically no change has been made. BTW, Reference.lyx does not seem to be available through the help menu. Why is this? if Reference.lyx does not deserve a whole menu item, perhaps we could have a new menuitem "Other docs" which includes Reference.lyx as a child document. -- John C. McCabe-Dansted Masters Student
