Qt frontend screenshot

Using the QT frontend, we get anti-aliased fonts for free: http://www.math.tau.ac.il/~dekelts/lyx/qt.png

Re: cvs compile

Andre Poenitz wrote: > On Fri, Jul 19, 2002 at 08:26:09AM +0200, Herbert Voss wrote: > >>after John's last commit >> > > What happens if you replace the "0" by string("0") there? that solves one problem, but in FormsMathDelim.C i had to write lv_->getLyXFunc()->dispatch(LFUN_MATH_DELIM, os

Re: cvs compile

On Fri, Jul 19, 2002 at 08:26:09AM +0200, Herbert Voss wrote: > after John's last commit What happens if you replace the "0" by string("0") there? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)

cvs compile

after John's last commit Herbert g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/ -I../../../boost -isystem /usr/X11R6/include -g -O -finline-limit=500 -fno-exceptions -W -Wall -Winline -Winline -c ControlRef.C -MT ControlRef.lo -MD -MP -MF .deps/ControlRef

Re: scary_eqns.lyx doesn't travel well

On Thu, 18 Jul 2002, Andre Poenitz wrote: > On Thu, Jul 18, 2002 at 11:22:15AM +0200, Juergen Vigna wrote: > > >Please try the attached patch against 1.2.1cvs. > > > > And what are we doing with files saved by the user? Shouldn't > > this be fixed also in the reading part of 1.3.0? If the file >

Minibuffer patch -help me !

Below is a patch that makes the changes I discussed earlier. It works except for two bugs : 1) core dump on exit 2) t doesn't complete to anything, but ta will do I'm stuck on these ones, I would greatly appreciate any help ! thanks john Index: lyxfunc.C =

Re: Symlink bug

> "Helmut" == Helmut Neukirchen <[EMAIL PROTECTED]> writes: Helmut> Dear LyX-developers, LyX 1.2.0cvs still does abort if the Helmut> binary is called via a relative(!) symbolic link. I've the Helmut> following directory structure: Hello, Thanks for your nice analysis. This made me actually

Re: Is there a better way?

On Thu, Jul 18, 2002 at 04:48:31PM +0100, Angus Leeming wrote: > Anyway, I see that nobody is being particularly thoughtful out there, > so I take it that nobody knows of a better way to > "rm ${BASE}* except ${BASE}.tex" > > So let's end this. ... by putting a '#' in front of it? ;^) A

Re: test for available packeges

On Thu, Jul 18, 2002 at 06:07:46PM +0200, Herbert Voss wrote: > what is the best way to store the list of all available > latex packages. at this time I have > > vector packageList; > > bool packageAvailable(string const & p) > { > // lyxrc.noPackageCheck allows a LaTeX-run without >

Re: [PATCH] next dispatch patch

On Thu, Jul 18, 2002 at 05:36:34PM +0200, Jean-Marc Lasgouttes wrote: > You should set the fontstate (or whatever) message only if > the lfun has not provided its own message. How difficult is > that? That already happens, that isn't where the problem is occuring. But if you do : LFUN_

Re: Is there a better way?

Angus Leeming wrote: > On Thursday 18 July 2002 5:05 pm, Herbert Voss wrote: > >>but it saves time and helped me a lot to answer >>user-questions >>this is the first thing I do, a # in front of >>these lines ... >> > > What are you talking about? user word says that his preview doesn't w

Re: Is there a better way?

On Thursday 18 July 2002 5:05 pm, Herbert Voss wrote: > but it saves time and helped me a lot to answer > user-questions > this is the first thing I do, a # in front of > these lines ... What are you talking about? Anyway, I see that nobody is being particularly thoughtful out there, so I

test for available packeges

what is the best way to store the list of all available latex packages. at this time I have vector packageList; bool packageAvailable(string const & p) { // lyxrc.noPackageCheck allows a LaTeX-run without // any check bool found = find(packageList.begin(), packageLis

Re: Is there a better way?

On Thu, Jul 18, 2002 at 04:38:08PM +0100, Angus Leeming wrote: > > yes, do nothing, then they are deleted when the user > > quits lyx ... > > That's not elegant at all. Does it hurt? It saves a few cycles... Andre' -- Those who desire to give up Freedom in order to gain Security, will not hav

Re: Is there a better way?

Angus Leeming wrote: > On Thursday 18 July 2002 4:56 pm, Herbert Voss wrote: > >>>Is there a more elegant way to invoke rm and remove these files? >> >>yes, do nothing, then they are deleted when the user >>quits lyx ... > > > That's not elegant at all. > Yes, but at least the user has the op

Re: Is there a better way?

Angus Leeming wrote: > On Thursday 18 July 2002 4:56 pm, Herbert Voss wrote: > >>>Is there a more elegant way to invoke rm and remove these files? >>> >>yes, do nothing, then they are deleted when the user >>quits lyx ... >> > > That's not elegant at all. but it saves time and helped me a lot

Re: Is there a better way?

On Thursday 18 July 2002 4:56 pm, Herbert Voss wrote: > > Is there a more elegant way to invoke rm and remove these files? > > yes, do nothing, then they are deleted when the user > quits lyx ... That's not elegant at all.

Re: Is there a better way?

Angus Leeming wrote: > In a shell script > (lyxpreview2ppm_new.sh actually, so not /totally/ off topic ;-) > > BAIL_OUT () { > # Remove everything except the original .tex file. > FILES=`ls ${BASE}* | sed -e "/${BASE}.tex/d"` > rm -f ${FILES} > exit 1 > } > > Is there a

Is there a better way?

In a shell script (lyxpreview2ppm_new.sh actually, so not /totally/ off topic ;-) BAIL_OUT () { # Remove everything except the original .tex file. FILES=`ls ${BASE}* | sed -e "/${BASE}.tex/d"` rm -f ${FILES} exit 1 } Is there a more elegant way to invoke rm and r

Re: src/stamp-h.inT

Angus Leeming wrote: > What's it there for? And why have I got cvs diff giving me: It seems that it has been here forever, but I suspect that it should not. This is something used by automake, I think. JMarc

Re: [PATCH] next dispatch patch

John Levon wrote: > On Thu, Jul 18, 2002 at 04:09:44PM +0200, Andre Poenitz wrote: > > >>? > > > e.g. C-m, one message overwrites another (and in several other cases) > insert->math->cases didn't clear minibuffer > > Most ->message() calls aren't going to be too useful. You should set the f

Re: lyx 1.2.0 + gcc 3.1

On Thu, Jul 18, 2002 at 11:32:10AM -0400, Kuba Ober wrote: > > I have 3.1 running and can compile 1.2.1cvs > > I cannot :-((( > > gcc-3.1, xforms-0.96, up-to-date rawhide system Did you configure --with-included-strings? If so, why? Andre' -- Those who desire to give up Freedom in order to

Re: lyx 1.2.0 + gcc 3.1

On środa 17 lipiec 2002 09:54 am, you wrote: > Kuba Ober wrote: > > Does anybody have patches for lyx to cleanly compile under gcc-3.1 (+ > > xforms-0.89)? > > what patches do you need? > > I have 3.1 running and can compile 1.2.1cvs I cannot :-((( gcc-3.1, xforms-0.96, up-to-date rawhide system

Re: [PATCH] next dispatch patch

On Thu, Jul 18, 2002 at 04:09:44PM +0200, Andre Poenitz wrote: > ? e.g. C-m, one message overwrites another (and in several other cases) insert->math->cases didn't clear minibuffer Most ->message() calls aren't going to be too useful. But we can work on these ... john -- "Of all manifestat

Re: preview.sty

On Thu, Jul 18, 2002 at 02:40:49PM +0100, Angus Leeming wrote: > > This is what I'm using. See if it works for you. > > Angus > > well.. ??? Real Life is keeping me busy... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, eit

Re: [PATCH] next dispatch patch

On Thu, Jul 18, 2002 at 02:53:34PM +0100, John Levon wrote: > There are some mathed problems with various things but I have the > feeling I'm tickling latent problems there rather than introducing new > ones ? Andre' -- Those who desire to give up Freedom in order to gain Security, will not ha

Re: preview.sty

On Thursday 18 July 2002 12:11 pm, Angus Leeming wrote: > On Thursday 18 July 2002 10:00 am, Andre Poenitz wrote: > > And I'd prefer if you did it as I lost the touch with the preview stuff > > and it currently "does not work" for me... > > This is what I'm using. See if it works for you. > Angus

Re: [PATCH] next dispatch patch

On Thu, Jul 18, 2002 at 03:49:29PM +0200, Jean-Marc Lasgouttes wrote: > Nothing there makes me jump to the ceiling. Fine praise indeed ! > I cannot test much :( Maybe I should just apply it and we can see what breaks compared to what I've fixed There are some mathed problems with various thin

Re: [PATCH] next dispatch patch

John Levon wrote: > Contains a couple more previously discussed changes. Please test this > so we can see what problems there might be. > > If there are no objections I'll commit it later. Nothing there makes me jump to the ceiling. However, since I had the good idea to apply a mandrake security

Re: [PATCH] next dispatch patch

On Thu, Jul 18, 2002 at 02:34:34PM +0100, John Levon wrote: > If there are no objections I'll commit it later. I like the lines starting with '-' in the patch ;-) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jeffer

[PATCH] next dispatch patch

Contains a couple more previously discussed changes. Please test this so we can see what problems there might be. If there are no objections I'll commit it later. thanks john Index: LyXAction.C === RCS file: /usr/local/lyx/cvsroo

src/stamp-h.inT

What's it there for? And why have I got cvs diff giving me: Index: src/stamp-h.in === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/stamp-h.in,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 stamp-h.in --- src/stamp-h.in 27

Re: Monitoring a file

Herbert Voss wrote: > Angus Leeming wrote: > >> Herbert, I think that the niceFile check should be moved to the top of >> the method. Am I correct or have I missed something obvious? > > > > correct, because it could be in latex, but I see, that > we get some more if-then-else, not good. > s

Re: [PATCH][RFC] dispatch work

On Thu, Jul 18, 2002 at 02:17:37PM +0200, Jean-Marc Lasgouttes wrote: > You mean that showState is not called anymore? view_state_changed you mean :) I'm not sure why it changed to be honest. > It would be nice to have > it called everytime the lfun has not set the minibuffer message. But it

Re: [PATCH][RFC] dispatch work

On Thu, Jul 18, 2002 at 01:14:37PM +0100, John Levon wrote: > I'm doing a great job of explaining myself badly. What I mean is, when > you press font-emph on toolbar, the minibuffer no longer shows > "Font Emphasis On" in response. > > I don't think that's a major deal because the user knows what

Re: [PATCH][RFC] dispatch work

John Levon wrote: > On Thu, Jul 18, 2002 at 01:57:57PM +0200, Jean-Marc Lasgouttes wrote: > > >>>o font-emph on toolbar no longer shows the change of mode. A problem ? >> >>Definitely. The toolbar should be updated on each action. > > > I'm doing a great job of explaining myself badly. :) >

Re: [PATCH][RFC] dispatch work

On Thu, Jul 18, 2002 at 01:57:57PM +0200, Jean-Marc Lasgouttes wrote: > >o font-emph on toolbar no longer shows the change of mode. A problem ? > > Definitely. The toolbar should be updated on each action. I'm doing a great job of explaining myself badly. What I mean is, when you press font-emp

Re: Monitoring a file

Angus Leeming wrote: > Herbert, I think that the niceFile check should be moved to the top of the > method. Am I correct or have I missed something obvious? correct, because it could be in latex, but I see, that we get some more if-then-else, not good. so move it to the beginning Herbert

Re: [PATCH][RFC] dispatch work

John Levon wrote: > This patch cleans up some things, but also introduces some problems. > Comments please. > > o font-emph on toolbar no longer shows the change of mode. A problem ? Definitely. The toolbar should be updated on each action. JMarc

Re: Monitoring a file

Herbert, I think that the niceFile check should be moved to the top of the method. Am I correct or have I missed something obvious? Angus string const InsetGraphics::prepareFile(Buffer const *buf) const { + // "nice" means that the buffer is exported to LaTeX format but not + //

Re: Monitoring a file

Herbert Voss wrote: > in prepareFile() we have a test for an existing copy of the > original file > >// if the file doen't exists, copy it into the tempd > if (!IsFileReadable(temp_file)) { > > > the easiest way is to have another bool fileChanged > > if (!IsFileRead

Re: preview.sty

On Thursday 18 July 2002 10:00 am, Andre Poenitz wrote: > And I'd prefer if you did it as I lost the touch with the preview stuff and > it currently "does not work" for me... This is what I'm using. See if it works for you. Angus preview-latex.tar.gz Description: GNU Zip compressed data

Re: Monitoring a file

On Thu, Jul 18, 2002 at 01:15:25PM +0200, Herbert Voss wrote: > for latex it's unimportant, but we hold a copy of the original > in the tempdir and therefore had to replace this when it changed. I wonder whether changing this copy to a soft link would not be a simpler solution. Andre' -- Those

Re: preview.sty

On Thu, Jul 18, 2002 at 11:45:27AM +0100, Angus Leeming wrote: > > So does the configure stuff recognize preview.sty already? > > No. Why should it? So that we can disable preview if preview.sty does not > exist or if the existing version is too old? Well, so kind of warning that preview won't

Re: Monitoring a file

Angus Leeming wrote: > People have complained since time began that "I change my eps file with an not me ... ;-) > I have a question, however: does LyX regenerate the file for a LaTeX run? If > it does regenerate it, does it do so every time InsetGraphics::latex is > called, irrespective of

Re: preview.sty

On Thursday 18 July 2002 10:03 am, Andre Poenitz wrote: > On Thu, Jul 18, 2002 at 11:02:17AM +0200, Herbert Voss wrote: > > there is no need that lyx stores these files, it depends to the > > latex stuff and there it should be, in the latex-tree ... > > So does the configure stuff recognize previe

Re: [PATCH][RFC] dispatch work

On Thu, Jul 18, 2002 at 11:58:04AM +0100, John Levon wrote: > This patch cleans up some things, but also introduces some problems. > [...] > o command-sequence stuff e.g. math-mutate from menus just shows > "(command sequence)" in the result I don't think this as a serious problem. Andre' --

Monitoring a file

People have complained since time began that "I change my eps file with an external program but LyX doesn't update its view". Well I can report that now it does. Attached is the patch. Note, however, that if you delete the graphics file, you'll get the "File does not exist" box, but if you p

[PATCH][RFC] dispatch work

This patch cleans up some things, but also introduces some problems. Comments please. o font-emph on toolbar no longer shows the change of mode. A problem ? o command-sequence stuff e.g. math-mutate from menus just shows "(command sequence)" in the result o probably other problems regards joh

Re: Dependencies utterly horked

On Thursday 18 July 2002 11:25 am, you wrote: > On Thu, Jul 18, 2002 at 10:38:57AM +0100, Angus Leeming wrote: > > > moz frontends 195 touch LyXView.h > > > moz frontends 196 make LyXView.o > > > make: `LyXView.o' is up to date. > > > > Your build and src dir are different and so you've just creat

Re: Dependencies utterly horked

On Thu, Jul 18, 2002 at 10:38:57AM +0100, Angus Leeming wrote: > > moz frontends 195 touch LyXView.h > > moz frontends 196 make LyXView.o > > make: `LyXView.o' is up to date. > > Your build and src dir are different and so you've just created an empty > LyXView.h in the build dir, not seen by M

Re: scary_eqns.lyx doesn't travel well

Angus Leeming wrote: > On Thursday 18 July 2002 10:46 am, Herbert Voss wrote: > >>Andre Poenitz wrote: >> > On Thu, Jul 18, 2002 at 11:22:15AM +0200, Juergen Vigna wrote: >> >>>Please try the attached patch against 1.2.1cvs. >> >> >> >>And what are we doing with files saved by the user? Shouldn'

Re: Dependencies utterly horked

On Thursday 18 July 2002 10:53 am, John Levon wrote: > moz frontends 195 touch LyXView.h > moz frontends 196 make LyXView.o > make: `LyXView.o' is up to date. > > ideas ? Your build and src dir are different and so you've just created an empty LyXView.h in the build dir, not seen by Makefile? A

Re: scary_eqns.lyx doesn't travel well

On Thursday 18 July 2002 10:46 am, Herbert Voss wrote: > Andre Poenitz wrote: > > On Thu, Jul 18, 2002 at 11:22:15AM +0200, Juergen Vigna wrote: > >>>Please try the attached patch against 1.2.1cvs. > >> > >>And what are we doing with files saved by the user? Shouldn't > >>this be fixed also i

Dependencies utterly horked

moz frontends 195 touch LyXView.h moz frontends 196 make LyXView.o make: `LyXView.o' is up to date. ideas ? john -- "Of all manifestations of power, restraint impresses the most." - Thucydides

Re: scary_eqns.lyx doesn't travel well

Andre Poenitz wrote: > On Thu, Jul 18, 2002 at 11:22:15AM +0200, Juergen Vigna wrote: > >>>Please try the attached patch against 1.2.1cvs. >>> >>And what are we doing with files saved by the user? Shouldn't >>this be fixed also in the reading part of 1.3.0? If the file >>is saved with 1.2.

Re: scary_eqns.lyx doesn't travel well

On Thu, Jul 18, 2002 at 11:22:15AM +0200, Juergen Vigna wrote: > >Please try the attached patch against 1.2.1cvs. > > And what are we doing with files saved by the user? Shouldn't > this be fixed also in the reading part of 1.3.0? If the file > is saved with 1.2.0 then the file is "doomed"? Good

Re: scary_eqns.lyx doesn't travel well

Andre Poenitz wrote: > On Thu, Jul 18, 2002 at 05:27:47PM +1000, Allan Rae wrote: > >>The scary_eqns.lyx file we've used in the past for some maths testing >>results in errors in 1.3.0 after conversion by 1.2.1cvs. > > > The problem are the braces in the label. > > Please try the attached patc

Re: graphics inset and external material

On Thursday 18 July 2002 09:27, Angus Leeming wrote: > > > > We have discussed that 2 years ago, in the middle of the Oslo fjord. > > The conclusion is: yes, it should, only needs someone to do it. ;-) > > Isn't it more complex than that; Asger mentioned this recently. The > external Inset does

Re: preview.sty

On Thu, Jul 18, 2002 at 11:02:17AM +0200, Herbert Voss wrote: > there is no need that lyx stores these files, it depends to the > latex stuff and there it should be, in the latex-tree ... So does the configure stuff recognize preview.sty already? Andre' -- Those who desire to give up Freedom i

Re: graphics inset and external material

On Thu, Jul 18, 2002 at 11:00:01AM +0200, Herbert Voss wrote: > do the whole lyx community a favour: > instead of looking around what could be or not > update the math-menu for 1.2.1 ... This would be no fun *grumble* Andre' -- Those who desire to give up Freedom in order to gain Security, wil

Re: preview.sty

Angus Leeming wrote: > On Thursday 18 July 2002 9:33 am, Andre Poenitz wrote: > >>Can't we put preview.sty into lib/tex? >> >>Andre' >> > > Sure. It's GPL code. But it's one more file to maintain. > > When 0.73 is released in the next week or so, I'll strip out a chunk of the > code in our Pr

Re: preview.sty

On Thu, Jul 18, 2002 at 09:32:30AM +0100, Angus Leeming wrote: > Sure. It's GPL code. But it's one more file to maintain. But's easier to have a version known to work distributed with LyX then to have everybody to hunt down the file himself. Especially if both sides are 'work in progress' and as

Re: graphics inset and external material

Andre Poenitz wrote: > Why do we have both of them? > > Wouldn't it be sensible if there were just one with combined functionality? do the whole lyx community a favour: instead of looking around what could be or not update the math-menu for 1.2.1 ... Herbert -- http://www.lyx.org/help/

Re: graphics inset and external material

On Thu, Jul 18, 2002 at 09:46:24AM +0100, José Abílio Oliveira Matos wrote: > We have discussed that 2 years ago, in the middle of the Oslo fjord. The > conclusion is: yes, it should, only needs someone to do it. ;-) Bu as far as I can see Jean-Marc was the only one actively working on increasin

Re: preview.sty

On Thursday 18 July 2002 9:33 am, Andre Poenitz wrote: > Can't we put preview.sty into lib/tex? > > Andre' Sure. It's GPL code. But it's one more file to maintain. When 0.73 is released in the next week or so, I'll strip out a chunk of the code in our Preview files and make greater use of the l

Re: graphics inset and external material

On Thursday 18 July 2002 9:46 am, José Abílio Oliveira Matos wrote: > On Thursday 18 July 2002 09:28, Andre Poenitz wrote: > > Why do we have both of them? > > > > Wouldn't it be sensible if there were just one with combined > > functionality? > > We have discussed that 2 years ago, in the middl

Re: graphics inset and external material

On Thursday 18 July 2002 09:28, Andre Poenitz wrote: > Why do we have both of them? > > Wouldn't it be sensible if there were just one with combined functionality? We have discussed that 2 years ago, in the middle of the Oslo fjord. The conclusion is: yes, it should, only needs someone to do i

Re: CVS generates empty Makefiles. Due to latest update in configure.in/acconfig.h?

Jean-Marc Lasgouttes wrote: > > Can you send your config.status? Attached, together with the config.log. Rob. config.status.bz2 Description: Binary data config.log.bz2 Description: Binary data

preview.sty

Can't we put preview.sty into lib/tex? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)

Re: configure: what means "checking X11/flimage.h usability... no" ?

Jean-Marc Lasgouttes wrote: > >On Wednesday 17 July 2002 11:05 am, R. Lahaye wrote: >> This is where it comes from: >> >> 113 typedef Window FL_WINDOW; /* unsigned long */ >> >> 539 typedef struct flps_cntl_ FLIMAGE_PS_OPTION; 540 FL_EXPORT >> FLPS_CONTROL *flimage_ps_options(void); >> >> 549 e

Re: CVS generates empty Makefiles. Due to latest update in configure.in/acconfig.h?

> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Jean-Marc, R> I've seen that you removed some unnecessary code from configure.in R> and acconfig.h in CVS. Removed too much? Or rather changed something I shouldn't have :( R> Since today's update to CVS, my configure script generates only R

graphics inset and external material

Why do we have both of them? Wouldn't it be sensible if there were just one with combined functionality? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)

Re: Compiling qt2?

> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Wed, Jul 17, 2002 at 11:20:50PM +0200, Jean-Marc Lasgouttes John> wrote: >> I tried for fun to compile with qt2 frontend, and all I got is John> one day it will not just be fun :) >> What can I do? Automake is 1.4-p5 John> Yes as

Re: cvs compile

On Wednesday 17 July 2002 8:35 pm, Herbert Voss wrote: > in src/graphics/Makefile.am > > are FileMonitor.[Ch] but not present as files > > Herbert Thank you Herbert. Fixed. A

Re: scary_eqns.lyx doesn't travel well

On Thu, Jul 18, 2002 at 09:31:33AM +0200, Andre' Poenitz wrote: > Apart from that I can't reproduce it here... ... since I had no plain 1.2.1cvs, but some changes in my tree... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either o

Re: scary_eqns.lyx doesn't travel well

On Thu, Jul 18, 2002 at 05:27:47PM +1000, Allan Rae wrote: > The scary_eqns.lyx file we've used in the past for some maths testing > results in errors in 1.3.0 after conversion by 1.2.1cvs. The problem are the braces in the label. Please try the attached patch against 1.2.1cvs. Jean-Marc: Shoul

Re: scary_eqns.lyx doesn't travel well

On Thu, Jul 18, 2002 at 05:27:47PM +1000, Allan Rae wrote: > The scary_eqns.lyx file we've used in the past for some maths testing > results in errors in 1.3.0 after conversion by 1.2.1cvs. > > http://www.devel.lyx.org/~rae/scary_eqns.lyx > > load into lyx-1.2.x, save it (so it's a version 1.3.0

scary_eqns.lyx doesn't travel well

The scary_eqns.lyx file we've used in the past for some maths testing results in errors in 1.3.0 after conversion by 1.2.1cvs. http://www.devel.lyx.org/~rae/scary_eqns.lyx load into lyx-1.2.x, save it (so it's a version 1.3.0cvs can read) now load it into 1.3.0cvs. I get: ... Line ~123: Math

Re: bug in mathed

On Thu, Jul 18, 2002 at 09:11:42AM +0200, Herbert Voss wrote: > when having the multline environment, lyx shows in all > lines the #-character, but only the last line is > numbered for the multline-env, the others can't! > > the alt-m-N has also to be disabled for the other > lines. Could you fi