Re: a plea for XML, was RE: file format
Andre Poenitz [EMAIL PROTECTED] writes: | Thanks for the idea, but I think *I* won't need sponsoring unless | it happens in form of source code (preferably a DTD by Jose' ;-) ) | or goodwill from the others when it comes to including the patches... | But maybe the project as a whole could use a few bucks... And we already have a page setup for that: http://www.devel.lyx.org/funding.php3 I can asure you that we will have no probliem in finding good use for any contribution. Lgb
Re: Small Project: File-Open... and Version Control
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars You know that after the addition of a realy regex class we can Lars do things like Lars "*.(lyx|lyx,v)" Lars If we did not massage the regex in the filedialog we could do Lars ".*\.lyx(,v)*" Lars in the filebrowser. Making RCS/*.lyx,v work is harder since you Lars then have to scan another directory too, that would probably Lars mean changes to the filedialog. In fact, this should not go into the regex used, but the filedialog should do it transparently for all files... Just an idea, since I'm not going to do it :) JMarc
Re: file format
Andre Poenitz wrote: I'd actually prefer ocirc; since this is non-ambiguous. Writing 8 bit in some encoding make life only simpler if you are reading the .lyx with the naked eye if you happen to use the correct enconding. And that should happen only in vary rare circumstances. It's true that even if, say ISO-8859-8, is written at the beginning of the file, it doesn't help us get the correct encoding automatically in a simple text editor. However, on the other hand, ; is useful and meaningful only for Latin-1 letters and simple Greek letters (with accents). To simply analysis, take a 8 bit non-Latin-1 encoding, say iso8859-8 for Hebrew (because that's the lastest success in LyX) as example. You see, in this encoding (as well as others, of course), if we have to use xxx; for non-Ascii characters, we could only write numeric forms because there's no entities for these (non-Latin1 characters). For example, take the letter "aleph", its code is \xE0 in ISO-8859-8 (correct me if I'm wrong), and thus it has to be written as #xE0; or #224; In this case, it's as ambiguous as using the binary value and it's not hard to imagine that this isn't readable either to naked eyes. The same problem will occur if Unicode (UTF-8) is used in the future. That's why it's absolutely necessary to precise the encoding at the very beginning of the file. But of course, we could have a compromise: for well-known entities like Aacute; szlig; etc, ; format is used. Otherwise, binary code is used. But the final decision is up to you because for normal users, it's very rare they have to read lyx file in a text editor :) The current format is not perfect (You'll notice this once you try to write a parser for it ;-)). If we switch to XML(...ish) we get a lot of cake for free: Everybody who writes a XML-to-something converter automatically writes a LYX-to-thesamething converter. Currently only LyX itself can read .lyx, and that is not tolerable in a setting where interoperability matters. I see. If we expect LyX-2-something converter to be written by others based on Xml-2-something, maybe we should use stricter Xml structure/syntax, no? Of course, this is the 'Correct Way'. However, LyX's internal structure does exactly look like what I 'translated'. The section's title is marked as 'Section', the content as 'Standard'. The 'Correct Way' would probably be to change the internals, too. But let's do this slowly ;-) I just remember that in latex, it's also written \section, right? Well, maybe we could change nothing at all. But we could invent another tag to englobe the whole section (well, if it's possible). Seak
Re: Small Project: File-Open... and Version Control
"Juergen" == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen When opening a Help-File from the src-dir, which now in
Juergen ./lib/doc/ does not anymore contain the LyX-Help-Files it
Juergen happens that it cannot find it. Strangely when starting from
Juergen the source-directory it ONLY searches the Help-files in the
Juergen same source-directory and does not get back to the
Juergen system-lyxdir(/usr/local/share/lyc), as in this case
Juergen system-lyxdir IS the source directory.
It is not, since I personally never install development releases :) So
the documentation is potentially not the same.
One (better of course) idea I had is that configure could check
whether ${top_srcdir}/../lyxdocs (the CVS repository) exists and, if
it does, create a symbolic link from it to lib/docs. Would that seem
reasonable?
JMarc
Re: a plea for XML, was RE: file format
Andre Poenitz wrote:
*grin* Aehm... yes... now as you mention it... Part of my vision
is some interface to some computer algebra system. If LyX had this, I
could demonstrate my boss that LyX is indeed superior to Scientific
Workplace ;--)
You remind me something. Since the example file is too big, I failed to
find the mathematical formula. How is it written? Latex syntax like \frac{},
\int{} are used and embedded as string in attribute value? Or MathML is used?
We have to think of this seriously. After all, mathematic typesetting
constitute an important part in latex, and scientific community is its main
supporter.
Seak
Re: Lyx crashes with Alt+Enter
"Jose" == Jose Abilio Oliveira Matos [EMAIL PROTECTED] writes: Jose Hi, this report should be for Lars, I think. Jose Start a new document, press g or any other letter for that Jose matter. Type Alt+Enter and ... lyx crashes reporting out of Jose memory. Indeed. Bug found and squashed. Lars, this is an instance in LyXParagraph::BreakParagraph of calling vector::reserve(pos_end - pos) where pos_end pos. Since these are unsigned... you know what happens %-| There is another suspicious instace of reserve() later that I fixed too, just in case... I'll commit soon. JMarc
Re: Bug report for LyX 1.0.3
"Dongsuk Chae" == 䵿¼® [EMAIL PROTECTED] writes: Dongsuk Chae Hi This is a bug report for LyX 1.0.3. Dongsuk Chae Problem Description While Dongsuk Chae you are editing in LyX, 1. Start a math panel 2. Pop up Dongsuk Chae one of the Greek to Misc panel 3. Click the Close Dongsuk Chae button(Not the one in math panel but the one beside Dongsuk Chae resize button on the title bar of math panel) 4. Then Dongsuk Chae LyX end up with following message. Hello, Thanks for the report. This bug has been fixed in lyx 1.0.4 (and subsequent releases, obviously). JMarc
Re: Lyx crashes with Alt+Enter
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Jose" == Jose Abilio Oliveira Matos [EMAIL PROTECTED] writes: | | Jose Hi, this report should be for Lars, I think. | | Jose Start a new document, press g or any other letter for that | Jose matter. Type Alt+Enter and ... lyx crashes reporting out of | Jose memory. | | Indeed. Bug found and squashed. Lars, this is an instance in | LyXParagraph::BreakParagraph of calling vector::reserve(pos_end - pos) | where pos_end pos. Since these are unsigned... you know what happens | %-| | | There is another suspicious instace of reserve() later that I fixed | too, just in case... Note that the reserve's are not really needed, they are just a feeble atemt to optimize a bit. So reserve's that look suspisous and that have no obvious right form, can just be deleted. Lgb
Re: Lyx crashes with Alt+Enter
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Note that the reserve's are not really needed, they are just a Lars feeble atemt to optimize a bit. Lars So reserve's that look suspisous and that have no obvious right Lars form, can just be deleted. Well, they are probably a good idea with large paragraphs, and testing whether reservation is needed probably does not hurt performance, so I propose to leave it as is. JMarc
ideas: colors, windows and scroll speed
I recently finished writing my PhD thesis in Lyx. It is a great product. These are a couple of new feature suggestions and remarks on the existing. It would be nice to be able to highlight parts of the displayed text. We use highlighter pens when working with paper drafts, don't we? A similar thing should be implemented in the paperless technology. This should not affect printing. It would be extremely convenient to be able to open an additional window, especially if one works with a large document like a thesis. I don't like how scroll works in lyx. It is too fast during selection. The sroll bar becomes too sensitive if the text is very large. There should be easily accessible options to controll the speed. I would also like to have the focus switched from the math panel to the main window automatically. Otherwise one has to click the border of the main window. If you miss the border and click the text, then the text cursor is moved and you have to perform several actions to get back. ...On the other hand this makes us, users, learn shortcuts. A minor bug. I struggled to input a very wide table. It is displayed with incorrect width of fields. It would be also nice to have a smooth scroll option. I know, I know... xforms limitations, increased bandwidth... Many, many thanks to the LyX team Alex
Bibtex problem found
Lars,
I found out why I had problems with bibtex. In RunBibtex, the regexp
used are
LRegex reg1("bibdata{([^}]+)}");
LRegex reg2("bibstyle{([^}]+)}");
I appears that my regex() verison considers that {} is a special
operator (whereas gnu grep seem to use \{\} for some weird reason), so
the following has to be used:
LRegex reg1("bibdata\\{([^}]+)\\}");
LRegex reg2("bibstyle\\{([^}]+)\\}");
A solution might be to _always_ use the provided GNU regex package...
JMarc
Re: Transitional series PR beta
Hmmm, looks like Lyx 1.1.4 is almost finished. As you know I have experienced a lot of problems when compiling Lyx with Sun CC (which IMHO are no problems of Sun CC). I also uncovered a lot of runtime errors when running Lyx with Purify (it just takes me a few minutes to find some new bugs). That brings me to the question whether there will be some code-freeze after which only bugs can be fixed. Currently, I am not very happy with the stability of certain features of Lyx and I would be very glad if you gave me the chance to investigate certain situations. Let's say one or two days for "customer acceptance testing" after code freeze :-) Michael PS: I will be able to do further testing on Saturday (provided that I am able to create an executable file). == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de ==
Re: Transitional series PR beta
Michael Schmitt [EMAIL PROTECTED] writes: | Hmmm, | | looks like Lyx 1.1.4 is almost finished. | | As you know I have experienced a lot of problems when compiling Lyx with | Sun CC (which IMHO are no problems of Sun CC). I also uncovered a lot of | runtime errors when running Lyx with Purify | (it just takes me a few minutes to find some new bugs). Purify does not nessiccarily detect runtime erros, it more like constructs to be wary about. | That brings me to the question whether there will be some code-freeze | after which only bugs can be fixed. We will slow down a bit now, and I will release a new prerelease tomorrow. If you have trouble compiling, have more output from purify now is the time for it. | Currently, I am not very happy with | the stability of certain features of Lyx Name them. | and I would be very glad if you | gave me the chance to investigate certain situations. Let's say one or two | days for "customer acceptance testing" after code freeze :-) Praps' | PS: I will be able to do further testing on Saturday (provided that I am | able to create an executable file). All bug reports are welcome. Lgb
Re: Bibtex problem found
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Lars,
|
| I found out why I had problems with bibtex. In RunBibtex, the regexp
| used are
| LRegex reg1("bibdata{([^}]+)}");
| LRegex reg2("bibstyle{([^}]+)}");
|
| I appears that my regex() verison considers that {} is a special
| operator (whereas gnu grep seem to use \{\} for some weird reason), so
| the following has to be used:
| LRegex reg1("bibdata\\{([^}]+)\\}");
| LRegex reg2("bibstyle\\{([^}]+)\\}");
|
| A solution might be to _always_ use the provided GNU regex
| package...
Hmm, I thought I had this set to POSIX_EXTENDED. Seems thate there are
different opinions about what POSIX_EXTENDED is. Using a regex lib
that we provide is of course a solution.
Or, we could rewrite the bibtex log file (.aux) parser to not use
regex's
Lgb
Compile errors: LyX 1.1.3, AIX 4.3.2
I compiled Lyx 1.1.3 on AIX 4.3.2 using gcc 2.95.2. There were two minor errors that prevented successful compilation: 1) In src/support/filetools.C, about line 322: The call to putenv fails. The putenv requires a char* argument, at least on AIX. I had to add a cast. Unless some systems prototype putenv with a const char* parameter, I think this is portable. 2) In src/spellchecker.C, about line 359, the FD_ZERO macro is used. When compiled, there is a complaint on this line that bzero is missing a prototype. FD_ZERO uses bzero. As a kludge, I added a #include strings.h. But I think a more portable solution would be to have configure check if bzero is prototype'd and available, defining a macro in terms of memset otherwise, and making sure code can use either or both of bzero and memset. I hope these comments are useful. /Lindsay R. Lindsay Todd email: [EMAIL PROTECTED] Senior Systems Programmer phone: 518-276-2605 Rensselaer Polytechnic Institute FAX: 518-276-2809 Troy, NY 12180-3590 WWW: http://www.rpi.edu/~toddr
Bug report
First, I want to report that I'm still working on the Hebrew patch.
It is now very functional.
On another matter, I've been using (normal) LyX to write a paper and found
several bugs. The most annoying ones are bugs with math macros:
Bug1:
The cursor behaves badly when deleting a character in an argument of a
math macro.
e.g. try to delete the 'X' in \binom{X+Y}{2} by either delete or backspace.
The character is deleted, but the cursor jumps down.
Bug2:
Define a math macro \x to be 2^{#1} and then enter \x{a+b} in math-mode.
When moving the cursor on the argument of the macro (a+b), the
cursor is displayed in a wrong position.
I think that this problem occurs since the math editor doesn't take into
account the font size of the macro's argument while moving the cursor
(it is taken into account when drawing the macro).
Bug3:
Enter The following in math-mode:
2^\binom{A+B}{2} \binom{A+B}{2}
The result is wrong: The first binom appears in small font, while the
second binom appears in small font.
Besides these bug, I found more (less annoying) bugs:
- A macro can be used even after deleting its definition in the text.
- LyX crashes when trying to enter a recursive math-macro
The error message is:
Macro2 x 5 Math error: Attempting to clean a void array.
Segmentation fault
- Deletion of a math-delim pair can not be done by pressing backspace
after the 2nd delimiter.
- When selecting the nominator (or denominator) of a fraction,
the height of the selection highlight is too big
- The cursor is viewed incorrectly when it is just before a math-display
formula (it appears at the row of the formula).
- When a layout with label starts with a math-display formula, the
label is printed at the row of the formula
- When entering URL in a footnote in the author layout,
the following error occurs while running Latex:
! Use of \@xfootnotemark doesn't match its definition.
- Error messages from latex(or checktex) are displayed in wrong positions
(I think it happens when there are math macros)
- Spell checking is very slow (much slower than klyx)
Finally, the following are display quirks:
- The comma in math-mode looks bad (e.g $i,j$)
- There isn't enough space between the sum symbols in
\sum_{i=1}^{9}\sum_{j=1}^{9} when using math-display formula
Re: a plea for XML, was RE: file format
Andre Poenitz <[EMAIL PROTECTED]> writes: | Thanks for the idea, but I think *I* won't need sponsoring unless | it happens in form of source code (preferably a DTD by Jose' ;-) ) | or goodwill from the others when it comes to including the patches... | But maybe the project as a whole could use a few bucks... And we already have a page setup for that: http://www.devel.lyx.org/funding.php3 I can asure you that we will have no probliem in finding good use for any contribution. Lgb
Re: Small Project: File->Open... and Version Control
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> You know that after the addition of a realy regex class we can Lars> do things like Lars> "*.(lyx|lyx,v)" Lars> If we did not massage the regex in the filedialog we could do Lars> ".*\.lyx(,v)*" Lars> in the filebrowser. Making RCS/*.lyx,v work is harder since you Lars> then have to scan another directory too, that would probably Lars> mean changes to the filedialog. In fact, this should not go into the regex used, but the filedialog should do it transparently for all files... Just an idea, since I'm not going to do it :) JMarc
Re: file format
Andre Poenitz wrote: > I'd actually prefer since this is non-ambiguous. > > Writing 8 bit in some encoding make life only simpler if you are reading > the .lyx with the naked eye if you happen to use the correct enconding. > And that should happen only in vary rare circumstances. It's true that even if, say ISO-8859-8, is written at the beginning of the file, it doesn't help us get the correct encoding automatically in a simple text editor. However, on the other hand, is useful and meaningful only for Latin-1 letters and simple Greek letters (with accents). To simply analysis, take a 8 bit non-Latin-1 encoding, say iso8859-8 for Hebrew (because that's the lastest success in LyX) as example. You see, in this encoding (as well as others, of course), if we have to use for non-Ascii characters, we could only write numeric forms because there's no entities for these (non-Latin1 characters). For example, take the letter "aleph", its code is \xE0 in ISO-8859-8 (correct me if I'm wrong), and thus it has to be written as or In this case, it's as ambiguous as using the binary value and it's not hard to imagine that this isn't readable either to naked eyes. The same problem will occur if Unicode (UTF-8) is used in the future. That's why it's absolutely necessary to precise the encoding at the very beginning of the file. But of course, we could have a compromise: for well-known entities like etc, format is used. Otherwise, binary code is used. But the final decision is up to you because for normal users, it's very rare they have to read lyx file in a text editor :) > The current format is not perfect (You'll notice this once you try to > write a parser for it ;-)). If we switch to XML(...ish) we get a lot of > cake for free: Everybody who writes a XML-to-something converter > automatically writes a LYX-to-thesamething converter. Currently only LyX itself can > read .lyx, and that is not tolerable in a setting where > interoperability matters. I see. If we expect LyX-2-something converter to be written by others based on Xml-2-something, maybe we should use stricter Xml structure/syntax, no? > Of course, this is the 'Correct Way'. However, LyX's internal structure does exactly > look like what I 'translated'. The section's title is marked as > 'Section', the content as 'Standard'. > The 'Correct Way' would probably be to change the internals, too. > But let's do this slowly ;-) I just remember that in latex, it's also written \section, right? Well, maybe we could change nothing at all. But we could invent another tag to englobe the whole section (well, if it's possible). Seak
Re: Small Project: File->Open... and Version Control
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> When opening a Help-File from the src-dir, which now in
Juergen> ./lib/doc/ does not anymore contain the LyX-Help-Files it
Juergen> happens that it cannot find it. Strangely when starting from
Juergen> the source-directory it ONLY searches the Help-files in the
Juergen> same source-directory and does not get back to the
Juergen> system-lyxdir(/usr/local/share/lyc), as in this case
Juergen> system-lyxdir IS the source directory.
It is not, since I personally never install development releases :) So
the documentation is potentially not the same.
One (better of course) idea I had is that configure could check
whether ${top_srcdir}/../lyxdocs (the CVS repository) exists and, if
it does, create a symbolic link from it to lib/docs. Would that seem
reasonable?
JMarc
Re: a plea for XML, was RE: file format
Andre Poenitz wrote:
> *grin* Aehm... yes... now as you mention it... Part of my vision
> is some interface to some computer algebra system. If LyX had this, I
> could demonstrate my boss that LyX is indeed superior to Scientific
> Workplace ;--)
You remind me something. Since the example file is too big, I failed to
find the mathematical formula. How is it written? Latex syntax like \frac{},
\int{} are used and embedded as string in attribute value? Or MathML is used?
We have to think of this seriously. After all, mathematic typesetting
constitute an important part in latex, and scientific community is its main
supporter.
Seak
Re: Lyx crashes with Alt+Enter
> "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes: Jose> Hi, this report should be for Lars, I think. Jose> Start a new document, press g or any other letter for that Jose> matter. Type Alt+Enter and ... lyx crashes reporting out of Jose> memory. Indeed. Bug found and squashed. Lars, this is an instance in LyXParagraph::BreakParagraph of calling vector::reserve(pos_end - pos) where pos_end < pos. Since these are unsigned... you know what happens %-| There is another suspicious instace of reserve() later that I fixed too, just in case... I'll commit soon. JMarc
Re: Bug report for LyX 1.0.3
> "Dongsuk Chae" == 䵿¼® <[EMAIL PROTECTED]> writes: Dongsuk Chae> Hi This is a bug report for LyX 1.0.3. Dongsuk Chae> Problem Description While Dongsuk Chae> you are editing in LyX, 1. Start a math panel 2. Pop up Dongsuk Chae> one of the Greek to Misc panel 3. Click the Close Dongsuk Chae> button(Not the one in math panel but the one beside Dongsuk Chae> resize button on the title bar of math panel) 4. Then Dongsuk Chae> LyX end up with following message. Hello, Thanks for the report. This bug has been fixed in lyx 1.0.4 (and subsequent releases, obviously). JMarc
Re: Lyx crashes with Alt+Enter
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes: | | Jose> Hi, this report should be for Lars, I think. | | Jose> Start a new document, press g or any other letter for that | Jose> matter. Type Alt+Enter and ... lyx crashes reporting out of | Jose> memory. | | Indeed. Bug found and squashed. Lars, this is an instance in | LyXParagraph::BreakParagraph of calling vector::reserve(pos_end - pos) | where pos_end < pos. Since these are unsigned... you know what happens | %-| | | There is another suspicious instace of reserve() later that I fixed | too, just in case... Note that the reserve's are not really needed, they are just a feeble atemt to optimize a bit. So reserve's that look suspisous and that have no obvious right form, can just be deleted. Lgb
Re: Lyx crashes with Alt+Enter
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Note that the reserve's are not really needed, they are just a Lars> feeble atemt to optimize a bit. Lars> So reserve's that look suspisous and that have no obvious right Lars> form, can just be deleted. Well, they are probably a good idea with large paragraphs, and testing whether reservation is needed probably does not hurt performance, so I propose to leave it as is. JMarc
ideas: colors, windows and scroll speed
I recently finished writing my PhD thesis in Lyx. It is a great product. These are a couple of new feature suggestions and remarks on the existing. It would be nice to be able to highlight parts of the displayed text. We use highlighter pens when working with paper drafts, don't we? A similar thing should be implemented in the paperless technology. This should not affect printing. It would be extremely convenient to be able to open an additional window, especially if one works with a large document like a thesis. I don't like how scroll works in lyx. It is too fast during selection. The sroll bar becomes too sensitive if the text is very large. There should be easily accessible options to controll the speed. I would also like to have the focus switched from the math panel to the main window automatically. Otherwise one has to click the border of the main window. If you miss the border and click the text, then the text cursor is moved and you have to perform several actions to get back. ...On the other hand this makes us, users, learn shortcuts. A minor bug. I struggled to input a very wide table. It is displayed with incorrect width of fields. It would be also nice to have a smooth scroll option. I know, I know... xforms limitations, increased bandwidth... Many, many thanks to the LyX team Alex
Bibtex problem found
Lars,
I found out why I had problems with bibtex. In RunBibtex, the regexp
used are
LRegex reg1("bibdata{([^}]+)}");
LRegex reg2("bibstyle{([^}]+)}");
I appears that my regex() verison considers that {} is a special
operator (whereas gnu grep seem to use \{\} for some weird reason), so
the following has to be used:
LRegex reg1("bibdata\\{([^}]+)\\}");
LRegex reg2("bibstyle\\{([^}]+)\\}");
A solution might be to _always_ use the provided GNU regex package...
JMarc
Re: Transitional series PR beta
Hmmm, looks like Lyx 1.1.4 is almost finished. As you know I have experienced a lot of problems when compiling Lyx with Sun CC (which IMHO are no problems of Sun CC). I also uncovered a lot of runtime errors when running Lyx with Purify (it just takes me a few minutes to find some new bugs). That brings me to the question whether there will be some code-freeze after which only bugs can be fixed. Currently, I am not very happy with the stability of certain features of Lyx and I would be very glad if you gave me the chance to investigate certain situations. Let's say one or two days for "customer acceptance testing" after code freeze :-) Michael PS: I will be able to do further testing on Saturday (provided that I am able to create an executable file). == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de ==
Re: Transitional series PR beta
Michael Schmitt <[EMAIL PROTECTED]> writes: | Hmmm, | | looks like Lyx 1.1.4 is almost finished. | | As you know I have experienced a lot of problems when compiling Lyx with | Sun CC (which IMHO are no problems of Sun CC). I also uncovered a lot of | runtime errors when running Lyx with Purify | (it just takes me a few minutes to find some new bugs). Purify does not nessiccarily detect runtime erros, it more like constructs to be wary about. | That brings me to the question whether there will be some code-freeze | after which only bugs can be fixed. We will slow down a bit now, and I will release a new prerelease tomorrow. If you have trouble compiling, have more output from purify now is the time for it. | Currently, I am not very happy with | the stability of certain features of Lyx Name them. | and I would be very glad if you | gave me the chance to investigate certain situations. Let's say one or two | days for "customer acceptance testing" after code freeze :-) Praps' | PS: I will be able to do further testing on Saturday (provided that I am | able to create an executable file). All bug reports are welcome. Lgb
Re: Bibtex problem found
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars,
|
| I found out why I had problems with bibtex. In RunBibtex, the regexp
| used are
| LRegex reg1("bibdata{([^}]+)}");
| LRegex reg2("bibstyle{([^}]+)}");
|
| I appears that my regex() verison considers that {} is a special
| operator (whereas gnu grep seem to use \{\} for some weird reason), so
| the following has to be used:
| LRegex reg1("bibdata\\{([^}]+)\\}");
| LRegex reg2("bibstyle\\{([^}]+)\\}");
|
| A solution might be to _always_ use the provided GNU regex
| package...
Hmm, I thought I had this set to POSIX_EXTENDED. Seems thate there are
different opinions about what POSIX_EXTENDED is. Using a regex lib
that we provide is of course a solution.
Or, we could rewrite the bibtex log file (.aux) parser to not use
regex's
Lgb
Compile errors: LyX 1.1.3, AIX 4.3.2
I compiled Lyx 1.1.3 on AIX 4.3.2 using gcc 2.95.2. There were two minor errors that prevented successful compilation: 1) In src/support/filetools.C, about line 322: The call to putenv fails. The putenv requires a char* argument, at least on AIX. I had to add a cast. Unless some systems prototype putenv with a const char* parameter, I think this is portable. 2) In src/spellchecker.C, about line 359, the FD_ZERO macro is used. When compiled, there is a complaint on this line that bzero is missing a prototype. FD_ZERO uses bzero. As a kludge, I added a #include . But I think a more portable solution would be to have configure check if bzero is prototype'd and available, defining a macro in terms of memset otherwise, and making sure code can use either or both of bzero and memset. I hope these comments are useful. /Lindsay R. Lindsay Todd email: [EMAIL PROTECTED] Senior Systems Programmer phone: 518-276-2605 Rensselaer Polytechnic Institute FAX: 518-276-2809 Troy, NY 12180-3590 WWW: http://www.rpi.edu/~toddr
Bug report
First, I want to report that I'm still working on the Hebrew patch.
It is now very functional.
On another matter, I've been using (normal) LyX to write a paper and found
several bugs. The most annoying ones are bugs with math macros:
Bug1:
The cursor behaves badly when deleting a character in an argument of a
math macro.
e.g. try to delete the 'X' in \binom{X+Y}{2} by either delete or backspace.
The character is deleted, but the cursor jumps down.
Bug2:
Define a math macro \x to be 2^{#1} and then enter \x{a+b} in math-mode.
When moving the cursor on the argument of the macro (a+b), the
cursor is displayed in a wrong position.
I think that this problem occurs since the math editor doesn't take into
account the font size of the macro's argument while moving the cursor
(it is taken into account when drawing the macro).
Bug3:
Enter The following in math-mode:
2^\binom{A+B}{2} \binom{A+B}{2}
The result is wrong: The first binom appears in small font, while the
second binom appears in small font.
Besides these bug, I found more (less annoying) bugs:
- A macro can be used even after deleting its definition in the text.
- LyX crashes when trying to enter a recursive math-macro
The error message is:
Macro2 x 5 Math error: Attempting to clean a void array.
Segmentation fault
- Deletion of a math-delim pair can not be done by pressing backspace
after the 2nd delimiter.
- When selecting the nominator (or denominator) of a fraction,
the height of the selection highlight is too big
- The cursor is viewed incorrectly when it is just before a math-display
formula (it appears at the row of the formula).
- When a layout with label starts with a math-display formula, the
label is printed at the row of the formula
- When entering URL in a footnote in the author layout,
the following error occurs while running Latex:
! Use of \@xfootnotemark doesn't match its definition.
- Error messages from latex(or checktex) are displayed in wrong positions
(I think it happens when there are math macros)
- Spell checking is very slow (much slower than klyx)
Finally, the following are display quirks:
- The comma in math-mode looks bad (e.g $i,j$)
- There isn't enough space between the sum symbols in
\sum_{i=1}^{9}\sum_{j=1}^{9} when using math-display formula
