Re: LyX dies when started on display :0.1
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Yes, we have had this complaint for a long time. I did find some problems at the time, but fixing them was obviously not enough. As far as I can tell, it always crashes at the same point for me. Thomas * dual head without xinerama (obviously) * different color Thomas depth on both screens (32 on first, 16 on second) Do you have a way to try with same depth on both screens? Yes, I did, but lyx still crashes. I tried 8, 16 and 24 bpp, (32 don't work on the second card). Unfortunately not. If you want to provide a trace, running with -sync would probably be useful. Ok, I did this. Recompiling lyx was really easy thanks to the debian package. I got the following trace when running $ cremer /tmp 0 lyx-1.2.2/src/lyx -sync a.lyx output -- stderr: Synchronous Mode Options Set debug:4 Visual:DefaultVisual (10) depth:0 privateColormap:0 sharedColormap:0 standardColormap:0 doubleBuffer:0 ulPropWidth:1 ulThickness:-1 scrollbarType:0 backingStore:1 coordUnit:pixel VisualId:0x0 rgamma:1.000 ggamma:1.000 bgamma:1.000 screen DPI=100.00 In BestVisual [flvisual.c 246] Initial visual: TrueColor(ID=0x3f) depth=24 In BestVisual [flvisual.c 256] ProgramDefault: TrueColor 24 In ReqVisual [flvisual.c 96] UserRequest: DefaultVisual 0 In BestVisual [flvisual.c 261] UserPreference: TrueColor 24 In ProgamVisual [flvisual.c 310] SelectedVisual: TrueColor(ID=0x3f) depth=24 In RGBInit [flvisual.c 71] TrueColor:bits_per_rgb=8 In RGBInit [flvisual.c 72] RS=16 GS=8 BS=0 In RGBInit [flvisual.c 73] RB=8 GB=8 BB=8 In RGBInit [flvisual.c 71] DirectColor:bits_per_rgb=8 In RGBInit [flvisual.c 72] RS=16 GS=8 BS=0 In RGBInit [flvisual.c 73] RB=8 GB=8 BB=8 In BestVisual [flcolor.c 650] MaxColors=16777216 PredefCol=32 In DefaultColormap [flcolor.c 677] 60 (0x3c) In ShareCmap [flcolor.c 475] Using default map 60 for TrueColor DefaultVisual=TrueColor CurrentVisual=TrueColor In FillMap [flcolor.c 338] Trying to get 32 colors got 0 ( 0 0 0) got 16777215 (255 255 255) got 10592673 (161 161 161) got 5855577 ( 89 89 89) got 2697513 ( 41 41 41) got 12566463 (191 191 191) got 14606046 (222 222 222) got 11316396 (172 172 172) got 9868950 (150 150 150) got 7434694 (113 113 198) got 13005169 (198 113 113) got 16711680 (255 0 0) got 255 ( 0 0 255) got 65280 ( 0 255 0) got 16776960 (255 255 0) got 16711935 (255 0 255) got 65535 ( 0 255 255) got 16737095 (255 99 71) got 7237230 (110 110 110) got 13421772 (204 204 204) got 7456369 (113 198 113) got 13473034 (205 149 10) got 13461961 (205 105 201) got 2665135 ( 40 170 175) got 9123366 (139 54 38) got 16770971 (255 231 155) got 1678 (255 128 0) got 16711808 (255 0 128) got 8453888 (128 255 0) got 8388863 (128 0 255) got 65408 ( 0 255 128) got 33023 ( 0 128 255) In InitCMap [flcolor.c 709] TrueColor Done In FLMap VClass:TrueColor VisualID:0x3f Depth:24 24 Colormap:0x3c In InitFont [fonts.c 121] Done GetResource lyx.geometry(LyX.geometryClass): None In NewPixmap [pixmap.c 150] Pixmap=58720272 mask=58720274 In NewPixmap [pixmap.c 150] Pixmap=58720277 mask=58720279 In NewPixmap [pixmap.c 150] Pixmap=58720282 mask=58720284 In NewPixmap [pixmap.c 150] Pixmap=58720287 mask=58720289 In NewPixmap [pixmap.c 150] Pixmap=58720292 mask=58720294 In NewPixmap [pixmap.c 150] Pixmap=58720297 mask=58720299 In NewPixmap [pixmap.c 150] Pixmap=58720302 mask=58720304 In NewPixmap [pixmap.c 150] Pixmap=58720307 mask=58720309 In NewPixmap [pixmap.c 150] Pixmap=58720312 mask=58720314 In NewPixmap [pixmap.c 150] Pixmap=58720317 mask=58720319 In NewPixmap [pixmap.c 150] Pixmap=58720322 mask=58720324 In NewPixmap [pixmap.c 150] Pixmap=58720327 mask=58720329 In NewPixmap [pixmap.c 150] Pixmap=58720332 mask=58720334 In NewPixmap [pixmap.c 150] Pixmap=58720337 mask=58720339 In NewPixmap [pixmap.c 150] Pixmap=58720342 mask=58720344 In NewPixmap [pixmap.c 150] Pixmap=58720347 mask=58720349 In WinOpen VClass:TrueColor VisualID:0x3f Depth:24 24 Colormap:0x3c CreateWin OK sleeping 1 seconds In CreateGC [flcolor.c 560] For TrueColor waiting Event(21,w=0x3800072 s=1282) ReparentNotify In Reparent [win.c 409] Full x=0 y=0 bw=0 In Reparent [win.c 422] Full x=3 y=26 bw=0 waiting Event(19,w=0x3800072 s=1282) MapNotify waiting Event(12,w=0x3800072 s=1282) Expose count=0 serial=502 In EventCallback [events.c 56] Unknown window=0x3800072 Ignored Event(12,w=0x3800072 s=1282) Expose count=0 serial=502 In WMReparent [win.c 463] Shift: reqy=177 y=203 In ObjPixmap [xsupport.c 253] Creating depth=24 for @2- In ObjPixmap [xsupport.c 253] Creating depth=24 for In ObjPixmap [xsupport.c 253] Creating depth=24 for In ObjPixmap
Re: LyX dies when started on display :0.1
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > Yes, we have had this complaint for a long time. I did find some > problems at the time, but fixing them was obviously not enough. As far as I can tell, it always crashes at the same point for me. > Thomas> * dual head without xinerama (obviously) * different color > Thomas> depth on both screens (32 on first, 16 on second) > > Do you have a way to try with same depth on both screens? Yes, I did, but lyx still crashes. I tried 8, 16 and 24 bpp, (32 don't work on the second card). > Unfortunately not. If you want to provide a trace, running with -sync > would probably be useful. Ok, I did this. Recompiling lyx was really easy thanks to the debian package. I got the following trace when running $ cremer /tmp 0 lyx-1.2.2/src/lyx -sync a.lyx >& output -- stderr: Synchronous Mode Options Set debug:4 Visual:DefaultVisual (10) depth:0 privateColormap:0 sharedColormap:0 standardColormap:0 doubleBuffer:0 ulPropWidth:1 ulThickness:-1 scrollbarType:0 backingStore:1 coordUnit:pixel VisualId:0x0 rgamma:1.000 ggamma:1.000 bgamma:1.000 screen DPI=100.00 In BestVisual [flvisual.c 246] Initial visual: TrueColor(ID=0x3f) depth=24 In BestVisual [flvisual.c 256] ProgramDefault: TrueColor 24 In ReqVisual [flvisual.c 96] UserRequest: DefaultVisual 0 In BestVisual [flvisual.c 261] UserPreference: TrueColor 24 In ProgamVisual [flvisual.c 310] SelectedVisual: TrueColor(ID=0x3f) depth=24 In RGBInit [flvisual.c 71] TrueColor:bits_per_rgb=8 In RGBInit [flvisual.c 72] RS=16 GS=8 BS=0 In RGBInit [flvisual.c 73] RB=8 GB=8 BB=8 In RGBInit [flvisual.c 71] DirectColor:bits_per_rgb=8 In RGBInit [flvisual.c 72] RS=16 GS=8 BS=0 In RGBInit [flvisual.c 73] RB=8 GB=8 BB=8 In BestVisual [flcolor.c 650] MaxColors=16777216 PredefCol=32 In DefaultColormap [flcolor.c 677] 60 (0x3c) In ShareCmap [flcolor.c 475] Using default map 60 for TrueColor DefaultVisual=TrueColor CurrentVisual=TrueColor In FillMap [flcolor.c 338] Trying to get 32 colors got 0 ( 0 0 0) got 16777215 (255 255 255) got 10592673 (161 161 161) got 5855577 ( 89 89 89) got 2697513 ( 41 41 41) got 12566463 (191 191 191) got 14606046 (222 222 222) got 11316396 (172 172 172) got 9868950 (150 150 150) got 7434694 (113 113 198) got 13005169 (198 113 113) got 16711680 (255 0 0) got 255 ( 0 0 255) got 65280 ( 0 255 0) got 16776960 (255 255 0) got 16711935 (255 0 255) got 65535 ( 0 255 255) got 16737095 (255 99 71) got 7237230 (110 110 110) got 13421772 (204 204 204) got 7456369 (113 198 113) got 13473034 (205 149 10) got 13461961 (205 105 201) got 2665135 ( 40 170 175) got 9123366 (139 54 38) got 16770971 (255 231 155) got 1678 (255 128 0) got 16711808 (255 0 128) got 8453888 (128 255 0) got 8388863 (128 0 255) got 65408 ( 0 255 128) got 33023 ( 0 128 255) In InitCMap [flcolor.c 709] TrueColor Done In FLMap VClass:TrueColor VisualID:0x3f Depth:24 24 Colormap:0x3c In InitFont [fonts.c 121] Done GetResource lyx.geometry(LyX.geometryClass): None In NewPixmap [pixmap.c 150] Pixmap=58720272 mask=58720274 In NewPixmap [pixmap.c 150] Pixmap=58720277 mask=58720279 In NewPixmap [pixmap.c 150] Pixmap=58720282 mask=58720284 In NewPixmap [pixmap.c 150] Pixmap=58720287 mask=58720289 In NewPixmap [pixmap.c 150] Pixmap=58720292 mask=58720294 In NewPixmap [pixmap.c 150] Pixmap=58720297 mask=58720299 In NewPixmap [pixmap.c 150] Pixmap=58720302 mask=58720304 In NewPixmap [pixmap.c 150] Pixmap=58720307 mask=58720309 In NewPixmap [pixmap.c 150] Pixmap=58720312 mask=58720314 In NewPixmap [pixmap.c 150] Pixmap=58720317 mask=58720319 In NewPixmap [pixmap.c 150] Pixmap=58720322 mask=58720324 In NewPixmap [pixmap.c 150] Pixmap=58720327 mask=58720329 In NewPixmap [pixmap.c 150] Pixmap=58720332 mask=58720334 In NewPixmap [pixmap.c 150] Pixmap=58720337 mask=58720339 In NewPixmap [pixmap.c 150] Pixmap=58720342 mask=58720344 In NewPixmap [pixmap.c 150] Pixmap=58720347 mask=58720349 In WinOpen VClass:TrueColor VisualID:0x3f Depth:24 24 Colormap:0x3c CreateWin OK sleeping 1 seconds In CreateGC [flcolor.c 560] For TrueColor waiting Event(21,w=0x3800072 s=1282) ReparentNotify In Reparent [win.c 409] Full x=0 y=0 bw=0 In Reparent [win.c 422] Full x=3 y=26 bw=0 waiting Event(19,w=0x3800072 s=1282) MapNotify waiting Event(12,w=0x3800072 s=1282) Expose count=0 serial=502 In EventCallback [events.c 56] Unknown window=0x3800072 Ignored Event(12,w=0x3800072 s=1282) Expose count=0 serial=502 In WMReparent [win.c 463] Shift: reqy=177 y=203 In ObjPixmap [xsupport.c 253] Creating depth=24 for @2-> In ObjPixmap [xsupport.c 253] Creating depth=24 for In ObjPixmap [xsupport.c 253] Creating depth=24 for In
Re: LyX dies when started on display :0.1
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: We have had reports of this kind some time ago already, but did not manage to identify and fix the problem. Can you run xforms programs (ie fdesign) succesfully? I don't have fdesign, but I tested xplot and xwatch, which work without any problem. The interesting aspect is that I have this problem on several computers, only on the second screen. And it has been there for a long time, so I think xforms 0.88, 0.89 and 1.0 are affected. Some common properties of the problematic systems: * dual head without xinerama (obviously) * different color depth on both screens (32 on first, 16 on second) * running a more or less recent Debian Linux on i386 * matrox cards for the second screen although I think I had the problem with an S3 card, too. I will provide a backtrace as soon as I find time to do so. Is an executable with debugging symbols available for download? That would simplify things a lot to me. Yours, Thomas [EMAIL PROTECTED]
Re: LyX dies when started on display :0.1
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > We have had reports of this kind some time ago already, but did not > manage to identify and fix the problem. Can you run xforms programs > (ie fdesign) succesfully? I don't have fdesign, but I tested xplot and xwatch, which work without any problem. The interesting aspect is that I have this problem on several computers, only on the second screen. And it has been there for a long time, so I think xforms 0.88, 0.89 and 1.0 are affected. Some common properties of the problematic systems: * dual head without xinerama (obviously) * different color depth on both screens (32 on first, 16 on second) * running a more or less recent Debian Linux on i386 * matrox cards for the second screen although I think I had the problem with an S3 card, too. I will provide a backtrace as soon as I find time to do so. Is an executable with debugging symbols available for download? That would simplify things a lot to me. Yours, Thomas <[EMAIL PROTECTED]>
LyX dies when started on display :0.1
Hi, it seems I found a strange bug in LyX when used on the second of two X screens. When I start X on the main screen (:0.0), everything is fine. But when I start on the second screen of my dual screen setup (:0.1), it crashes as soon as I open a new or an existing file. So I suppose it could be a problem with the control of the main text window. It says: BadMatch (invalid parameter attributes) id: 62914722 or similar. Is this a known problem? Sorry, I have no debugging symbols ATM, but if it helps, I will recompile lyx. I have had this problem with several versions of lyx, at least all the 1.2.x versions, and also with different binaries and different versions of xforms. Please send me a copy of an reply by email, since I am not on the list. Yours, Thomas [EMAIL PROTECTED]
LyX dies when started on display :0.1
Hi, it seems I found a strange bug in LyX when used on the second of two X screens. When I start X on the main screen (:0.0), everything is fine. But when I start on the second screen of my dual screen setup (:0.1), it crashes as soon as I open a new or an existing file. So I suppose it could be a problem with the control of the main text window. It says: BadMatch (invalid parameter attributes) id: 62914722 or similar. Is this a known problem? Sorry, I have no debugging symbols ATM, but if it helps, I will recompile lyx. I have had this problem with several versions of lyx, at least all the 1.2.x versions, and also with different binaries and different versions of xforms. Please send me a copy of an reply by email, since I am not on the list. Yours, Thomas <[EMAIL PROTECTED]>
Compiling for libc5?
Hi, I would like to compile lyx for libc5 (aout), so that I can use it with mulinux. gcc 2.7.2 is the latest compiler with support for libc5. Should that be possible in general? AFAIC autoconf works ok up the configuration of libsigc++. According to the website of libsigc++, it cannot be compiled using gcc 2.7.2, but a port should be possible. So has anyone tried to compile lyx for libc5? Is libsigc++ the only problem? Can it be solved? Thanks for any hint. Yours, Thomas [EMAIL PROTECTED]
Compiling for libc5?
Hi, I would like to compile lyx for libc5 (aout), so that I can use it with mulinux. gcc 2.7.2 is the latest compiler with support for libc5. Should that be possible in general? AFAIC autoconf works ok up the configuration of libsigc++. According to the website of libsigc++, it cannot be compiled using gcc 2.7.2, but a port should be possible. So has anyone tried to compile lyx for libc5? Is libsigc++ the only problem? Can it be solved? Thanks for any hint. Yours, Thomas <[EMAIL PROTECTED]>
Re: No more slush state.
Herbert Voss [EMAIL PROTECTED] writes: any comments to the gui? Seems ok, I especially like the Scale % thing. How is the % of column width handled? Is it in Width/Height? Maybe all the scaling could be combined? And I don't quite like the |#x lables. They just look a bit messy. Yours (unbiased by any thorough understanding of it :-)) Thomas [EMAIL PROTECTED]
Re: No more slush state.
Herbert Voss <[EMAIL PROTECTED]> writes: > any comments to the gui? Seems ok, I especially like the "Scale %" thing. How is the "% of column width" handled? Is it in Width/Height? Maybe all the scaling could be combined? And I don't quite like the |#x lables. They just look a bit messy. Yours (unbiased by any thorough understanding of it :-)) Thomas <[EMAIL PROTECTED]>
Re: euro as special character
Herbert Voss [EMAIL PROTECTED] writes: an euro, but I'm not able to insert it with the keyboard. in all insets, like label, figure a.s.o., I get the currency symbol with AltGr-e (the sputnik) which becomes after closing the inset window the eurosign. but in lyx main-gui - nothing What does # xmodmap -pke | grep 26 tell you? Mine is: keycode 26 = e E EuroSign currency This means AltGR-e gives me the Euro sign, which does not work in any application I have tried. AltGR-E gives results in the Euro sign if ISO-8859-15 is selected, but it is technically wrong. Infact, it points to the currency sign, which is the sputnik ¤ you mentioned. I don't have lyx-cvs, so I can't comment on its behaviour. I can only get the sputnik within LyX 1.1.6. Don't use a broken fix to work around a broken system. It will still be broken. Thomas [EMAIL PROTECTED]
Re: euro as special character
Herbert Voss <[EMAIL PROTECTED]> writes: > an euro, but I'm not able to insert it with the keyboard. > in all insets, like label, figure a.s.o., I get the currency > symbol with AltGr-e (the sputnik) which becomes after closing the > inset window the eurosign. but in lyx main-gui -> nothing What does # xmodmap -pke | grep 26 tell you? Mine is: keycode 26 = e E EuroSign currency This means AltGR-e gives me the Euro sign, which does not work in any application I have tried. AltGR-E gives results in the Euro sign if ISO-8859-15 is selected, but it is technically wrong. Infact, it points to the currency sign, which is the sputnik ¤ you mentioned. I don't have lyx-cvs, so I can't comment on its behaviour. I can only get the sputnik within LyX 1.1.6. Don't use a broken fix to work around a broken system. It will still be broken. Thomas <[EMAIL PROTECTED]>
Re: dramantic increases in forced rodent use
John Levon [EMAIL PROTECTED] writes: and for years, people have been forced to go to the manual to work out ^ some how to enter lengths. More recently, we have had a vague help message in some places. Other people have entered length just as they always did. The new interface makes it patently clear what we are expecting, and reduces the potential for user error. ACK. But it does make thing for people who know harder. This is basic good UI design [1] No, absolutely not. A good UI is not only easy but also convenient. This might be a bit hard for a GUI, but it is possible. What about the following idea: You can still enter length as usual, the parser recognises it and sets the drop-down list accordingly. Since the parser did check for correct units, and since the drop-down list is implemented, it should be only a little additional work. And it marks both sides happy. You could also go as far as XEmacs: provide two ways for every option. One keybord based in the status line and one pop-up window for rodent users. But this is of course a lot more work (though it is extremely fast to use). Thomas [EMAIL PROTECTED] -- Umweltfreundlich, da aus recycleten Buchstaben.
Re: dramantic increases in forced rodent use
John Levon <[EMAIL PROTECTED]> writes: > and for years, people have been forced to go to the manual to work out ^ some > how to enter lengths. More recently, we have had a vague help message > in some places. Other people have entered length just as they always did. > The new interface makes it patently clear what we are expecting, and > reduces the potential for user error. ACK. But it does make thing for "people who know" harder. > This is basic good UI design [1] No, absolutely not. A good UI is not only easy but also convenient. This might be a bit hard for a GUI, but it is possible. What about the following idea: You can still enter length as usual, the parser recognises it and sets the drop-down list accordingly. Since the parser did check for correct units, and since the drop-down list is implemented, it should be only a little additional work. And it marks both sides happy. You could also go as far as XEmacs: provide two ways for every option. One keybord based in the status line and one pop-up window for rodent users. But this is of course a lot more work (though it is extremely fast to use). Thomas <[EMAIL PROTECTED]> -- Umweltfreundlich, da aus recycleten Buchstaben.
Re: lyx file format changes
Herbert Voss [EMAIL PROTECTED] writes: why should I do a lyx-latex-lyx cycle? You need it if you work on a document with a coauthor which doesn't have LyX. this is the only reason?? It is the only reason for doing the cycle I can see. Having said that, interoperability in general is a pretty good reason, I think. A lot of texts I work with are written in LaTeX, not in LyX (and they are not even written by me :-)). So a decent import facility is important to me (with Lyx 1.1.5 is works quite ok). If the full cycle works correctly, it is just a sign of the latex import being well done. Concerning the aspects of a lyx document that do not appear in the latex file, I think they are of minor importance. Maybe a merge would be useful: take these from the old lyx document, and the text from latex. Thomas [EMAIL PROTECTED] -- Umweltfreundlich, da aus recycleten Buchstaben.
Re: lyx file format changes
Herbert Voss <[EMAIL PROTECTED]> writes: >>> why should I do a lyx->latex->lyx cycle? >> >> You need it if you work on a document with a coauthor which doesn't have LyX. > > this is the only reason?? It is the only reason for doing the cycle I can see. Having said that, interoperability in general is a pretty good reason, I think. A lot of texts I work with are written in LaTeX, not in LyX (and they are not even written by me :-)). So a decent import facility is important to me (with Lyx 1.1.5 is works quite ok). If the full cycle works correctly, it is just a sign of the latex import being well done. Concerning the aspects of a lyx document that do not appear in the latex file, I think they are of minor importance. Maybe a "merge" would be useful: take these from the old lyx document, and the text from latex. Thomas <[EMAIL PROTECTED]> -- Umweltfreundlich, da aus recycleten Buchstaben.
Re: Wishlist
Uli Sorger [EMAIL PROTECTED] writes: First, I'd like to have better large document support. Indeed. A folding mode would be cute... With TeX parts the document can be typeset using the \includeonly (?) command with correct cross references. You can typeset even part documents in latex, but of course the references go wrong. Another thing that auctex (Emacs) can do is to typeset just the marked region. Very nice if you want to check just a formula or two. ²) Is it possible to automate section/figure/table labelling? Yes, that's on my list, too. :-) Thomas [EMAIL PROTECTED] -- Umweltfreundlich, da aus recycleten Buchstaben.
Re: Wishlist
Uli Sorger <[EMAIL PROTECTED]> writes: > First, I'd like to have better large document support. Indeed. A folding mode would be cute... > With TeX parts the document can be typeset using the \includeonly (?) > command with correct cross references. You can typeset even "part" documents in latex, but of course the references go wrong. Another thing that auctex (Emacs) can do is to typeset just the marked region. Very nice if you want to check just a formula or two. > ²) Is it possible to automate section/figure/table labelling? Yes, that's on my list, too. :-) Thomas <[EMAIL PROTECTED]> -- Umweltfreundlich, da aus recycleten Buchstaben.
[Bug] Accents in math mode
Hi,
I discovered a bug in math mode. If you enter (in math mode)
\tilde \overline{x
you actually get
\overline{\tilde\{x}}
The same happens when a document is read, where the above sequence
appears. Since there is no LaTeX limitation concerning either form, I
believe this to be a bug. (It is possible to do the trick by using a
macro, but that leads to rather frequent crashes.)
I am using LyX 1.1.5fix2 (debian testing on x86), can any one verify
the bug on 1.6?
Thomas [EMAIL PROTECTED]
Re: [Bug] Accents in math mode
Herbert Voss [EMAIL PROTECTED] writes:
try \tilde{}\overline{x}
Which produces the same result, at least here. I can only produce the
above sequence editing the lyx-file by hand.
If I try to enter that construct using
\tilde{ \overline{ x
I get a very weird looking formula, which leads to latex code
\tilde{{}\overline{{a}}
which is of course invalid :-(
The same happens if I enter
\tilde{ - \overline{ x
(rightarrow to leave the {} )
I have read somewhere, that \tilde should be used without {}, which
seems to be correct...
Thomas [EMAIL PROTECTED]
Re: [Bug] Accents in math mode
Herbert Voss [EMAIL PROTECTED] writes: but anyway, why can't you use the lyx math panel? Fascinating idea. I hadn't thought that might to any good, but it does. The math panel uses \widetilde, which solves the problem. So the bug is still there, but at least I have a workaround. Now if we document it, does it become a feature? :-) Thomas [EMAIL PROTECTED]
[Bug] Accents in math mode
Hi,
I discovered a bug in math mode. If you enter (in math mode)
\tilde \overline{x
you actually get
\overline{\tilde\{x}}
The same happens when a document is read, where the above sequence
appears. Since there is no LaTeX limitation concerning either form, I
believe this to be a bug. (It is possible to do the trick by using a
macro, but that leads to rather frequent crashes.)
I am using LyX 1.1.5fix2 (debian testing on x86), can any one verify
the bug on 1.6?
Thomas <[EMAIL PROTECTED]>
Re: [Bug] Accents in math mode
Herbert Voss <[EMAIL PROTECTED]> writes:
> try \tilde{}\overline{x}
Which produces the same result, at least here. I can only produce the
above sequence editing the lyx-file by hand.
If I try to enter that construct using
\tilde{ \overline{ x
I get a very weird looking formula, which leads to latex code
\tilde{{}\overline{{a}}
which is of course invalid :-(
The same happens if I enter
\tilde{ -> \overline{ x
(rightarrow to leave the {} )
I have read somewhere, that \tilde should be used without {}, which
seems to be correct...
Thomas <[EMAIL PROTECTED]>
Re: [Bug] Accents in math mode
Herbert Voss <[EMAIL PROTECTED]> writes: > but anyway, why can't you use the lyx math panel? Fascinating idea. I hadn't thought that might to any good, but it does. The math panel uses \widetilde, which solves the problem. So the bug is still there, but at least I have a workaround. Now if we document it, does it become a feature? :-) Thomas <[EMAIL PROTECTED]>
Protected Space Incompatibility Lyx 1.1.4fix3 and 1.1.5fix2
Hello, I use LyX 1.1.4fix3 at home and LyX 1.1.5fix2 at work, that is i386 GNU/Linux Debian Potato and a current Debian Woody. Works like a charm, but: LyX 1.1.5 writes a construct that breaks 1.1.4: \layout Description a\SpecialChar ~ b c LyX 1.1.4 expects: \layout Description a\proctected_separator b c Unfortunately, reading the first may mess up the following line as well, so that your document is really shredded. Since LyX has been very compatible between version so far, I would appreciate it, if LyX 1.1.5fix3 would be compatible with older version again. If you want to reproduce the bug: Open a new document in lyx 1.1.5, set style to description, type a word, type C-space (protected space), type another word, space, and another word. Save that document and try to load it with lyx 1.1.4. Please note that I am not subscribed to the list, sorry, and there is no archive. So please send me an email-copy. Apologies if the bug is already known. Thomas [EMAIL PROTECTED]
Re: Protected Space Incompatibility Lyx 1.1.4fix3 and 1.1.5fix2
Angus Leeming [EMAIL PROTECTED] writes: I'm not sure anybody promised backward compatability... Anyway, it's not going to happen! Forward compatibility is Ok. Beg to differ. Forward compatibility is a must and therefore not worth mentioning. Backward compatibility is nice to have, and I would assume it between stable minor revisions. So far LyX *was* backward compatible, at least between the releases I have used (thats 1.0.1 to 1.1.5 IIRC). Remember the Word 97 thingy? If you're not going to upgrade and use the same version of lyx on both machines, then the following little file will do the trick: Obviously this is only the second best solution. It would certainly be nice to have this script in a complete form with some documentation in the distribution. Is this going to happen? If someone can point out the differences, I could at least collect them and try my best at a script (perl, that is :-)). sed -f conv_new2old.sed file_newformat.lyx file_oldformat.lyx Or a couple of keystrokes on XEmacs, yes, that is always possible. Once you know what the problem is. Remainder: please drop me a copy as well, I'm not on the list. Thomas [EMAIL PROTECTED]
Re: Protected Space Incompatibility Lyx 1.1.4fix3 and 1.1.5fix2
Angus Leeming [EMAIL PROTECTED] writes: Well, in general, it is impossible to be backward compatible always. By this I mean that changes to the file format cannot possibly be backward compatible. Yes, I understand that. And I am the last person to complain about a change to the better, even if it breaks backwards compatibility (Well ok, I *did* complain...). I was just puzzled by the fact that this is really the first file format problem ever that I came across, so I thought it might be a bug. There have not been many of these file format changes, however, so you've been lucky. Note, however, that lyx may move very soon to an xml file format. Yes, that makes sense (though having real latex as a file format would suit me even more, but I guess you have discussed that quite a lot). It will be possible to write a conversion script back to the old format, but that'll be the best we can do, I suspect. That's ok. If it is documented somewhere. Just the one thing about Word 97 (8): remember the file format was incompatible with Word 6 or 7? Some people really got mad about it, because it was really difficult to interoperate. Later Microsoft did provide export and import of the other format, but the PR damage was already done. Thomas [EMAIL PROTECTED]
Protected Space Incompatibility Lyx 1.1.4fix3 and 1.1.5fix2
Hello, I use LyX 1.1.4fix3 at home and LyX 1.1.5fix2 at work, that is i386 GNU/Linux Debian Potato and a current Debian Woody. Works like a charm, but: LyX 1.1.5 writes a construct that breaks 1.1.4: \layout Description a\SpecialChar ~ b c LyX 1.1.4 expects: \layout Description a\proctected_separator b c Unfortunately, reading the first may mess up the following line as well, so that your document is really shredded. Since LyX has been very compatible between version so far, I would appreciate it, if LyX 1.1.5fix3 would be compatible with older version again. If you want to reproduce the bug: Open a new document in lyx 1.1.5, set style to description, type a word, type C-space (protected space), type another word, space, and another word. Save that document and try to load it with lyx 1.1.4. Please note that I am not subscribed to the list, sorry, and there is no archive. So please send me an email-copy. Apologies if the bug is already known. Thomas <[EMAIL PROTECTED]>
Re: Protected Space Incompatibility Lyx 1.1.4fix3 and 1.1.5fix2
Angus Leeming <[EMAIL PROTECTED]> writes: > I'm not sure anybody promised backward compatability... Anyway, it's not > going to happen! Forward compatibility is Ok. Beg to differ. Forward compatibility is a must and therefore not worth mentioning. Backward compatibility is nice to have, and I would assume it between stable minor revisions. So far LyX *was* backward compatible, at least between the releases I have used (thats 1.0.1 to 1.1.5 IIRC). Remember the Word 97 thingy? > If you're not going to upgrade and use the same version of lyx on both > machines, then the following little file will do the trick: Obviously this is only the second best solution. It would certainly be nice to have this script in a complete form with some documentation in the distribution. Is this going to happen? If someone can point out the differences, I could at least collect them and try my best at a script (perl, that is :-)). > sed -f conv_new2old.sed < file_newformat.lyx > file_oldformat.lyx Or a couple of keystrokes on XEmacs, yes, that is always possible. Once you know what the problem is. Remainder: please drop me a copy as well, I'm not on the list. Thomas <[EMAIL PROTECTED]>
Re: Protected Space Incompatibility Lyx 1.1.4fix3 and 1.1.5fix2
Angus Leeming <[EMAIL PROTECTED]> writes: > Well, in general, it is impossible to be backward compatible always. > By this I mean that changes to the file format cannot possibly be > backward compatible. Yes, I understand that. And I am the last person to complain about a change to the better, even if it breaks backwards compatibility (Well ok, I *did* complain...). I was just puzzled by the fact that this is really the first file format problem ever that I came across, so I thought it might be a bug. > There have not been many of these file format changes, however, so > you've been lucky. Note, however, that lyx may move very soon to an > xml file format. Yes, that makes sense (though having real latex as a file format would suit me even more, but I guess you have discussed that quite a lot). > It will be possible to write a conversion script back to the old > format, but that'll be the best we can do, I suspect. That's ok. If it is documented somewhere. Just the one thing about Word 97 (8): remember the file format was incompatible with Word 6 or 7? Some people really got mad about it, because it was really difficult to interoperate. Later Microsoft did provide export and import of the other format, but the PR damage was already done. Thomas <[EMAIL PROTECTED]>
Crash in Math-Mode (lyx 1.0.1)
hi, ok, i'm still using lyx 1.0.1, which is a bit outdated, but maybe the bug is present in newer versions also. it is easy to reproduce: C-m ^ k [-] [-] \ a [BS] [BS] ^ Crash here ^ Cursor left^ Display goes weird here it takes about a second, the text is emergency safed (though the formula is messed up imho), and the following text is printed: Math Error: This is not an inset[107] lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. If possible, please read 'Known bugs' under the Help menu and then send us a full bug report. Thanks! LyX: Versuche Speichern des Dokuments /export/home/merkur/ts/unbenannt.lyx als... 1) /export/home/merkur/ts/unbenannt.lyx.emergency Speichern scheint gelungen zu sein. Glück gehabt! Bye. zsh: IOT instruction (core dumped) lyx Backtrace is (no debugging, unfortunately): #0 0xff216870 in _kill () #1 0xff1b92e0 in abort () #2 0x3b81c in __0FNerror_handleri () #3 signal handler called #4 0x186a98 in __0fMMathedCursorIdoAccentP6LMathedInset () #5 0x1842a4 in __0fMMathedCursorOMacroModeClosev () #6 0x1844d0 in __0fMMathedCursorNMacroModeBackv () #7 0x17f8b0 in __0fMMathedCursorELefti () #8 0x11d358 in __0fMInsetFormulaNLocalDispatchiPCc () #9 0xc83bc in __0fHLyXFuncIDispatchiPCc () #10 0xc6eb0 in __0fHLyXFuncPprocessKeyEventP6H_XEvent () #11 0x1cef60 in __0fHLyXViewZKeyPressMask_raw_callbackP6Gforms_PvT () #12 0xff2b7fac in do_interaction_step () #13 0xff2b8a48 in fl_treat_interaction_events () #14 0xff2b8a98 in fl_check_forms () #15 0x3ebd0 in __0fGLyXGUIHrunTimev () #16 0x35f54 in __0oDLyXctPiPPc () #17 0x35458 in main () (gdb) about my system: it is a sun ultra 1, running solaris 2.7. the lyx 1.0.1 binary i'm using is the one from www.sunfreeware.com, which also includes the necessary libraries. german nationalisation. PS: lyx is great, but one feature is missing: scaling images. say you want 50% of the original .eps size, there's no way to do that. maybe you can add a button... Thomas [EMAIL PROTECTED] (C) Copyright 1999 by Thomas Steffen, not to be forwarded -- linux, linuctis - f, das beste Betriebssystem ;-) [Tobi in doc]
Crash in Math-Mode (lyx 1.0.1)
hi, ok, i'm still using lyx 1.0.1, which is a bit outdated, but maybe the bug is present in newer versions also. it is easy to reproduce: C-m ^ k [<-] [<-] \ a [BS] [BS] ^ Crash here ^ Cursor left^ Display goes weird here it takes about a second, the text is emergency safed (though the formula is messed up imho), and the following text is printed: Math Error: This is not an inset[107] lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. If possible, please read 'Known bugs' under the Help menu and then send us a full bug report. Thanks! LyX: Versuche Speichern des Dokuments /export/home/merkur/ts/unbenannt.lyx als... 1) /export/home/merkur/ts/unbenannt.lyx.emergency Speichern scheint gelungen zu sein. Glück gehabt! Bye. zsh: IOT instruction (core dumped) lyx Backtrace is (no debugging, unfortunately): #0 0xff216870 in _kill () #1 0xff1b92e0 in abort () #2 0x3b81c in __0FNerror_handleri () #3 #4 0x186a98 in __0fMMathedCursorIdoAccentP6LMathedInset () #5 0x1842a4 in __0fMMathedCursorOMacroModeClosev () #6 0x1844d0 in __0fMMathedCursorNMacroModeBackv () #7 0x17f8b0 in __0fMMathedCursorELefti () #8 0x11d358 in __0fMInsetFormulaNLocalDispatchiPCc () #9 0xc83bc in __0fHLyXFuncIDispatchiPCc () #10 0xc6eb0 in __0fHLyXFuncPprocessKeyEventP6H_XEvent () #11 0x1cef60 in __0fHLyXViewZKeyPressMask_raw_callbackP6Gforms_PvT () #12 0xff2b7fac in do_interaction_step () #13 0xff2b8a48 in fl_treat_interaction_events () #14 0xff2b8a98 in fl_check_forms () #15 0x3ebd0 in __0fGLyXGUIHrunTimev () #16 0x35f54 in __0oDLyXctPiPPc () #17 0x35458 in main () (gdb) about my system: it is a sun ultra 1, running solaris 2.7. the lyx 1.0.1 binary i'm using is the one from www.sunfreeware.com, which also includes the necessary libraries. german nationalisation. PS: lyx is great, but one feature is missing: scaling images. say you want 50% of the original .eps size, there's no way to do that. maybe you can add a button... Thomas <[EMAIL PROTECTED]> (C) Copyright 1999 by Thomas Steffen, not to be forwarded -- linux, linuctis - f, das beste Betriebssystem ;-) [Tobi in doc]
