string question
Reading the documentation in lyxstring.h: "it is written to be a drop in replacement for STL string" which suggests that the configure option "--with-included-string" is just that --- an option. It is not, however. Configuring lyx (1.1.5 CVS) with "configure --without-included-string" leads to the following error: g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -g -O -fno-rtti -fno-exceptions -ansi -W -Wall -Wno-return-type -Wp,-MD,.deps/formula.pp -c formula.C -o formula.o formula.C: In method `void InsetFormula::display(bool)': formula.C:567: no matching function for call to `string::clear ()' There is some inconsistency here. Either lyxstring is meant to be a drop in replacement for STL string, in which case both configure options should work, Or it isn't, in which case, the configure option should be removed. Can someone out there explain to me "current thinking"! TIA, Angus
Did I fix the backspace bug?
Hello,
I just commited a fix to cvs which fixes for me the backspace-crash
that has been plaguing LyX for some time. Go try latest cvs and tell
me what happens. I am interested to know whether your favourite way of
crashing LyX still works and whether editing still works as intended.
If you are using lyx-1.1.4fix2, please try the appended patch. If it
works, I will release fix3 very soon.
JMarc
--- lyx-1.1.4fix2/src/text.CMon Jan 24 23:17:06 2000
+++ lyx-1.1.4fix3pre/src/text.C Tue Mar 28 12:24:51 2000
@@ -3029,9 +3029,22 @@
cursor.par->ParFromPos(cursor.pos)->previous->previous,
cursor.par->ParFromPos(cursor.pos)->next);
}
+
tmppar = cursor.par;
tmprow = cursor.row;
- CursorLeftIntern();
+ // We used to do CursorLeftIntern() here, but it is
+ // not a good idea since it triggers the auto-delete
+ // mechanism. So we do a CursorLeftIntern()-lite,
+ // without the dreaded mechanism. (JMarc)
+ if (cursor.pos > 0) {
+ SetCursorIntern(cursor.par, cursor.pos - 1);
+ }
+ else if (cursor.par->Previous()) {
+ // steps into the above paragraph.
+ SetCursorIntern(cursor.par->Previous(),
+ cursor.par->Previous()->Last());
+ }
+
/* Pasting is not allowed, if the paragraphs have different
layout. I think it is a real bug of all other
word processors to allow it. It confuses the user.
Re: LyX and supress LaTeX errors
> "Larry" == Larry Marso <[EMAIL PROTECTED]> writes: Larry> Some LyX files which produce Postscript output without a Larry> hiccup, when exported to LaTeX yields .tex files that will not Larry> compile without repeated halts complaining of overfull mboxes. Overfull mboxes do not halt compilation AFAIK. Could you show us an example log file? Larry> These errors can be bypassed with repeated (annoying) manual Larry> return key hits, but how does LyX tell LaTeX to ignore them? Larry> What can I do to bypass them, compiling the .tex files outside Larry> of LyX? Note that LyX used to be sloppy at finding errors, and this 'problem' has been fixed in 1.1.4fix2. It is always better to fix problems rather than to ignore them JMarc
Re: string question
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Reading the documentation in lyxstring.h: "it is written to be Angus> a drop in replacement for STL string" Angus> which suggests that the configure option Angus> "--with-included-string" is just that --- an option. It is not, Angus> however. Configuring lyx (1.1.5 CVS) with "configure Angus> --without-included-string" leads to the following error: Lyxstring is written to have a standard conformant string object on systems where STL strings are not good enough (for example, they do not have the clear() method required for the standard). The configure script tries to compile a short example program (using clear() in particular) and decides to use lyxstring when STL string is not good enough. Angus> There is some inconsistency here. Either lyxstring is meant to Angus> be a drop in replacement for STL string, in which case both Angus> configure options should work, Or it isn't, in which case, the Angus> configure option should be removed. It is just that your string implementation is not good enough... However, I had another nasty idea about these string problems: What about faking STL string with lyxstring when for the STL headers which require the header? I explain. LString.h could start like #ifndef LSTRING_H #define LSTRING_H #ifndef USE_INCLUDED_STRING #include using std::string; #else #ifdef __STRING__ #error The header has been included before LString.h #else #define __STRING__ #endif #include "support/lyxstring.h" typedef lyxstring string; #endif #endif This way, any time the real header is included, it will not load due to the fact that __STRING__ is already defined (if other implementation use other defines, we could provide them). The downside is that LString.h should be included before any STL header (we could force that by including LString.h in config.h...). I did not do it yet because I do not have much time now, but if Lars does not strongly objects, I think we should do that. It would also simplify a bit of the code with stringstreams. Opinions? JMarc
Re: string question
Many thanks for the explanation, JMarc! I conclude that egcs-1.1.2 causes code bloat and that its STL is not standards compliant! Onto your __STRING__ suggestion. I was trying to do something like this last night, albeit in a much more hacked way in order to resolve my problems in the rae branch of CVS: When compiling FormPrint.C: /usr/local/egcs/include/g++/string:9: conflicting types for `typedef class basic_string,__default_alloc_template > string' ../../../src/LString.h:20: previous declaration as `typedef class lyxstring string' I didn't succeed last night, but this must be the best way to go. Incidentally, using your suggestion, can you compile FormPrint.C in the rae branch using gcc? (You'll need to compile it with exception support turned on.) I'll try again this evening. Angus > However, I had another nasty idea about these string problems: What > about faking STL string with lyxstring when for the STL headers which > require the header? > I explain. LString.h could start like > #ifndef LSTRING_H > #define LSTRING_H > #ifndef USE_INCLUDED_STRING > #include > using std::string; > #else > #ifdef __STRING__ > #error The header has been included before LString.h > #else > #define __STRING__ > #endif > #include "support/lyxstring.h" > typedef lyxstring string; > #endif > #endif > This way, any time the real header is included, it will not > load due to the fact that __STRING__ is already defined (if other > implementation use other defines, we could provide them). The downside > is that LString.h should be included before any STL header (we could > force that by including LString.h in config.h...). > I did not do it yet because I do not have much time now, but if Lars > does not strongly objects, I think we should do that. It would also > simplify a bit of the code with stringstreams. > Opinions? > JMarc
RE: Did I fix the backspace bug?
On 28-Mar-2000 Jean-Marc Lasgouttes wrote:
>
> Hello,
>
> I just commited a fix to cvs which fixes for me the backspace-crash
> that has been plaguing LyX for some time. Go try latest cvs and tell
> me what happens. I am interested to know whether your favourite way of
> crashing LyX still works and whether editing still works as intended.
Well Jean-Marc I guess we need this to otherwise when doing Backspace()
in a situation like 'a | a' we get 'a|a' instead of 'a| a'. What do you
think?
Sorry no unified patch I only used my VC facility inside XEmacs to
visualize the diff of the actual Buffer to the last version ;)
mail continues below!!! ++
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.43
diff -c -r1.43 text.C
*** text.C 2000/03/28 10:22:19 1.43
--- text.C 2000/03/28 11:04:54
***
*** 3453,3459
SetUndo(Undo::DELETE,
cursor.par->ParFromPos(cursor.pos)->previous,
cursor.par->ParFromPos(cursor.pos)->next);
! CursorLeftIntern();
// some insets are undeletable here
if (cursor.par->GetChar(cursor.pos) == LyXParagraph::META_INSET) {
--- 3453,3471
SetUndo(Undo::DELETE,
cursor.par->ParFromPos(cursor.pos)->previous,
cursor.par->ParFromPos(cursor.pos)->next);
! // We used to do CursorLeftIntern() here, but it is
! // not a good idea since it triggers the auto-delete
! // mechanism. So we do a CursorLeftIntern()-lite,
! // without the dreaded mechanism. (JMarc)
! if (cursor.pos > 0) {
! SetCursorIntern(cursor.par, cursor.pos - 1);
! }
! else if (cursor.par->Previous()) {
! // steps into the above paragraph.
! SetCursorIntern(cursor.par->Previous(),
! cursor.par->Previous()->Last());
! }
! //CursorLeftIntern();
// some insets are undeletable here
if (cursor.par->GetChar(cursor.pos) == LyXParagraph::META_INSET) {
++
And one more CursorPositioning problem try to move the Cursor to the Right
in this situation 'a | a' you'll see that the cursor ends up blinking in the
middle of the second 'a'.
Jürgen
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug
There seems no plan because it is all plan.
-- C.S. Lewis
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Font crash
Hello! I am using a developer version of Lyx. I found the following: If I specify a non-existent font for screen_font_popup and screen_font_menu value in lyxrc, lyx will crash when trying to open a menu. Here is what I have in lyxrc: \screen_font_encoding ascii-0 \screen_font_roman "-monotype-web*hebrew*ad" \screen_font_sans "-monotype-web*hebrew*monospace" \screen_font_typewriter "-monotype-web*hebrew*monospace" \screen_font_popup "-*-fixed" \screen_font_menu "-*-fixed" No font exists for pattern -*-fixed-*-*-*-?-*-*-*-*-ascii-0. The messages produced are: Could not set menu font to -*-fixed-*-*-*-?-*-*-*-*-ascii-0 Could not set popup font to -*-fixed-*-*-*-?-*-*-*-*-ascii-0 Unable to open character set file BadFont (invalid Font parameter) [3]Abort /usr/devel/bin/lyx The correct behaviour would be to use fixed font (and possibly open a popup to warn the user about it). Generally, if a font is not found, a popup window should be open. Currently, only a message is printed to standard error. Hope this helps, MST -- This message content is not part of Intel's views or affairs Michael S. Tsirkin > Four things are to be strengthened: Torah,and good deeds, > prayer and one's good manners (Berachoth)
Re: using std... namespace std
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | This does not work with gcc 2.8.1 (as you might have guessed), but | does work with cxx and probably with sun CC 5.0 (which does not | compile out of the box yet). Ok... note that you are the only cause why I still (kindo want to) support gcc 2.8.x. | Lars, I know you'd really like to use std:: all over the code, but | I'd It is not that I want to use std:: all over, I just want to remove the using from the header files. | like to be able to continue a bit with gcc 2.8.1, as long as it is not | too painful. One reason is that it is my only way now to compile under | solaris (to get purify) and that I do _not_ intend to upgrade the | compiler used by 100+ persons here... | | Anyway, I am the one who have this crappy compiler, and I am the one | who has the other funky compiler which requires std::, so I can do the | work of adding 'using' directive when needed (I don't care). | Finally, That is the problem, we want to get rid of the using statements. | when we decide to drop it (in 10 years or so) Ha ha! , it is a matter of one | hour of work to remove 'using' directives and add std:: where it is | needed, so it is not really breaking LyX with lots of nasty | workarounds. | | So I think we should keep these directives for now, even though you | really seem to have an itch to scratch here. Especialy since I now compile only with the new stdc++ lib from gnu, with -fhonor-std turned on by default... Lgb
Re: patch
Gady Kozma <[EMAIL PROTECTED]> writes: | upgrade. There is no real issue her - it's just 10 lines of code. Just accept | it. Maintainability is a large issue. 0.81 is several years old, even 0.88 the current stable release of XForms is a couple of years old. When 0.90 is releases and proven stable we will also ditch support for 0.88 and then your 0.81 will have real problems. Besides I think your 0.81 patch just happens to work, there are some compability issues between 0.81 and0.88. Lgb
Re: [Fwd: compiling xtl?]
Angus Leeming <[EMAIL PROTECTED]> writes:
| The following works:
| template
| void composite(Stream & stream)
| {
| + int t, wp;
| + t = static_cast(target);
| + wp = static_cast(which_pages);
Please use:
int t = static_...
int wp = static_...
Lgb
Re: string question
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I did not do it yet because I do not have much time now, but if Lars | does not strongly objects, I think we should do that. It would also | simplify a bit of the code with stringstreams. Not true since other "objects" in the std::libs often use basic_string<...> directly. Lgb
Re: Did I fix the backspace bug?
Juergen Vigna <[EMAIL PROTECTED]> writes: | And one more CursorPositioning problem try to move the Cursor to the Right | in this situation 'a | a' you'll see that the cursor ends up blinking in the | middle of the second 'a'. That is a different problem and is for the time beeing put there on purpose. Lgb
Re: Font crash
Hello! Here is the crash stack: Program received signal SIGABRT, Aborted. 0x401254e1 in __kill () from /lib/libc.so.6 Current language: auto; currently c (gdb) backtrace #0 0x401254e1 in __kill () from /lib/libc.so.6 #1 0x40125156 in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x40126868 in abort () at ../sysdeps/generic/abort.c:88 #3 0x81353b7 in Letext () at abort.C:9 #4 0x80a582d in LyX_XErrHandler (display=0x82204a8, xeev=0xbfffe248) at lyx_gui.C:148 #5 0x4007bc5b in _XError () from /usr/X11R6/lib/libX11.so.6 #6 0x4007a3f1 in _XReply () from /usr/X11R6/lib/libX11.so.6 #7 0x40068e2f in XInternAtom () from /usr/X11R6/lib/libX11.so.6 #8 0x40082033 in XSetWMColormapWindows () from /usr/X11R6/lib/libX11.so.6 #9 0x8157dee in fl_showpup () at lyxstring.h:505 #10 0x81565f0 in fl_dopup () at lyxstring.h:505 #11 0x80cb82c in Menus::ShowFileMenu2 (ob=0x823fa58) at menus.C:752 #12 0x80c8122 in C_Menus_ShowFileMenu2 (ob=0x823fa58, data=0) at menus.C:71 #13 0x814bc6c in fl_object_qread () at lyxstring.h:505 #14 0x814a7ea in fl_check_forms () at lyxstring.h:505 #15 0x80a6d0d in LyXGUI::runTime (this=0x821d428) at lyx_gui.C:611 #16 0x80a803e in LyX::LyX (this=0xbfffefb8, argc=0xb060, argv=0xb0a4) at ../src/lyx_main.C:131 #17 0x80c80be in main (argc=1, argv=0xb0a4) at ../src/main.C:42 hmmm ... for some reason fl_showpup and fl_dopup show at line lyxstring.h:505. I couldn't find them there ... help someone? mst Quoting r. Michael Tsirkin ([EMAIL PROTECTED]) "Font crash": > Hello! > I am using a developer version of Lyx. > > I found the following: > If I specify a non-existent font for screen_font_popup > and screen_font_menu value in lyxrc, lyx will crash when > trying to open a menu. > > Here is what I have in lyxrc: > \screen_font_encoding ascii-0 > \screen_font_roman "-monotype-web*hebrew*ad" > \screen_font_sans "-monotype-web*hebrew*monospace" > \screen_font_typewriter "-monotype-web*hebrew*monospace" > \screen_font_popup "-*-fixed" > \screen_font_menu "-*-fixed" > > No font exists for pattern -*-fixed-*-*-*-?-*-*-*-*-ascii-0. > > The messages produced are: > > Could not set menu font to -*-fixed-*-*-*-?-*-*-*-*-ascii-0 > Could not set popup font to -*-fixed-*-*-*-?-*-*-*-*-ascii-0 > Unable to open character set file > BadFont (invalid Font parameter) > [3]Abort /usr/devel/bin/lyx > > The correct behaviour would be to use fixed font > (and possibly open a popup to warn the user about it). > > Generally, if a font is not found, a popup window should be open. > Currently, only a message is printed to standard error. > > Hope this helps, > MST > > -- > This message content is not part of Intel's views or affairs > Michael S. Tsirkin > > Four things are to be strengthened: Torah,and good deeds, > > prayer and one's good manners (Berachoth) -- This message content is not part of Intel's views or affairs Michael S. Tsirkin > Four things are to be strengthened: Torah,and good deeds, > prayer and one's good manners (Berachoth)
Re: using std... namespace std
Hello! Sorry if this was proposed before: std:: can be used with older g++ versions, I think if you add -Dstd= to the command line, or otherwise define std to the empty macro. It also works for other compilers. Could this be a solution? Quoting r. Lars Gullik Bjønnes ([EMAIL PROTECTED]) "Re: using std... namespace std": > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > | This does not work with gcc 2.8.1 (as you might have guessed), but > | does work with cxx and probably with sun CC 5.0 (which does not > | compile out of the box yet). > > Ok... note that you are the only cause why I still (kindo want to) > support gcc 2.8.x. > > | Lars, I know you'd really like to use std:: all over the code, but > | I'd > > It is not that I want to use std:: all over, I just want to remove the > using from the header files. > > | like to be able to continue a bit with gcc 2.8.1, as long as it is not > | too painful. One reason is that it is my only way now to compile under > | solaris (to get purify) and that I do _not_ intend to upgrade the > | compiler used by 100+ persons here... > | > | Anyway, I am the one who have this crappy compiler, and I am the one > | who has the other funky compiler which requires std::, so I can do the > | work of adding 'using' directive when needed (I don't care). > | Finally, > > That is the problem, we want to get rid of the using statements. > > | when we decide to drop it (in 10 years or so) > > Ha ha! > > , it is a matter of one > | hour of work to remove 'using' directives and add std:: where it is > | needed, so it is not really breaking LyX with lots of nasty > | workarounds. > | > | So I think we should keep these directives for now, even though you > | really seem to have an itch to scratch here. > > Especialy since I now compile only with the new stdc++ lib from gnu, > with -fhonor-std turned on by default... > > Lgb -- This message content is not part of Intel's views or affairs Michael S. Tsirkin > Four things are to be strengthened: Torah,and good deeds, > prayer and one's good manners (Berachoth)
Re: Did I fix the backspace bug?
On 28-Mar-2000 Lars Gullik Bjønnes wrote: > Juergen Vigna <[EMAIL PROTECTED]> writes: > >| And one more CursorPositioning problem try to move the Cursor to the Right >| in this situation 'a | a' you'll see that the cursor ends up blinking in the >| middle of the second 'a'. > > That is a different problem and is for the time beeing put there on > purpose. > Well I really don't think u put that there on purpose :) and I think we solved both problems already, didn't we? Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug Barbie says, Take quaaludes in gin and go to a disco right away! But Ken says, WOO-WOO!! No credit at "Mr. Liquor"!! -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Did I fix the backspace bug?
Juergen Vigna <[EMAIL PROTECTED]> writes: | Well I really don't think u put that there on purpose :) and I think | we solved both problems already, didn't we? P'raps. But I still did it on purpose! (belive me, belive me) Lgb
Re: using std... namespace std
"Michael S. Tsirkin" <[EMAIL PROTECTED]> writes: | Hello! | Sorry if this was proposed before: | std:: can be used with older g++ versions, I think if you add | -Dstd= to the command line, or otherwise define std to the empty macro. | It also works for other compilers. | Could this be a solution? Depends what you mean by "older g++ versions", older thatn 2.8.x will not work anyway, they just don't support the c++ language good enough. The "#define std" trick will perhaps buy something, but I don't think it will work always. besides I don't think we need it. Lgb
Re: using std... namespace std
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Ok... note that you are the only cause why I still (kindo want Lars> to) support gcc 2.8.x. Thanks for being so good to me :) Lars> That is the problem, we want to get rid of the using statements. The real question is 'why?'. Although I can see how some things other gcc 2.8 shortcoming may be bad and force a bad programming style, those using statements are really not a big pain... Lars> Especialy since I now compile only with the new stdc++ lib from Lars> gnu, with -fhonor-std turned on by default... So, in two months we will release a version of LyX which only compiles with a beta version of the next GNU C++ library. Great. JMarc
Re: using std... namespace std
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | The real question is 'why?'. Although I can see how some things other | gcc 2.8 shortcoming may be bad and force a bad programming style, | those using statements are really not a big pain... To have the global namespace clean. You don't introduce a name into the namespace (global or other) until you need it. Same as with not declaring variables until you need them. | Lars> Especialy since I now compile only with the new stdc++ lib from | Lars> gnu, with -fhonor-std turned on by default... | | So, in two months we will release a version of LyX which only | compiles with a beta version of the next GNU C++ library. Great. Jupp, and then I will be the only one beeing able to compile LyX. Lgb
bug in current CVS
LyX has a new bug when rendering text. If I write a paragraph, all is fine. If I then delete something in the middle of the paragraph, then the words wrap in a weird way. This is best seen with a little image, attached. Anybody else able to reproduce this? Angus waffle.gif
Re: bug in current CVS
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> --Boundary-=_mHPfybpSwAJCCvjOFJEEEBjzylne Content-Type: Angus> text/plain Content-Transfer-Encoding: 8bit Angus> LyX has a new bug when rendering text. If I write a paragraph, Angus> all is fine. If I then delete something in the middle of the Angus> paragraph, then the words wrap in a weird way. This is best Angus> seen with a little image, attached. Anybody else able to Angus> reproduce this? I do not see this. Are you sure it is the latest latest cvs (with Juergen fixes)? JMarc
Re: bug in current CVS
Hmmm. This is latest, latest CVS as it stands now (15:06BST) which I last updated (Ie, it changed last) when YOU posted your note about text.C. Juergen posted subsequent to this, but his changes appear not to be in CVS yet. Or at least, if they are, then I HAVE already included them. Put it this way, doing cvs update just this last second changed nothing. > Angus> LyX has a new bug when rendering text. If I write a paragraph, > Angus> all is fine. If I then delete something in the middle of the > Angus> paragraph, then the words wrap in a weird way. This is best > Angus> seen with a little image, attached. Anybody else able to > Angus> reproduce this? > > I do not see this. Are you sure it is the latest latest cvs (with > Juergen fixes)?
Re: bug in current CVS
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Hmmm. This is latest, latest CVS as it stands now (15:06BST) Angus> which I last updated (Ie, it changed last) when YOU posted your Angus> note about text.C. Juergen posted subsequent to this, but his Angus> changes appear not to be in CVS yet. Or at least, if they are, Angus> then I HAVE already included them. Angus> Put it this way, doing cvs update just this last second changed Angus> nothing. OK, OK, I believe you :) Might this have been caused by my 'fix'? I have to admit that I really do not know... I guess that, if a paragraph is modified but the corresponding row information is not, this kind of effect can occur. JMarc
Re: bug in current CVS
On 28-Mar-2000 Jean-Marc Lasgouttes wrote: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Hmmm. This is latest, latest CVS as it stands now (15:06BST) > Angus> which I last updated (Ie, it changed last) when YOU posted your > Angus> note about text.C. Juergen posted subsequent to this, but his > Angus> changes appear not to be in CVS yet. Or at least, if they are, > Angus> then I HAVE already included them. > > Angus> Put it this way, doing cvs update just this last second changed > Angus> nothing. > > OK, OK, I believe you :) Might this have been caused by my 'fix'? I > have to admit that I really do not know... I guess that, if a > paragraph is modified but the corresponding row information is not, > this kind of effect can occur. I cannot reproduce this. Could you send a small example file where this happens? Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug My pants just went to high school in the Carlsbad Caverns!!! -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Font crash
> "Michael" == Michael S Tsirkin <[EMAIL PROTECTED]> writes: Michael> Hello! I am using a developer version of Lyx. Michael> I found the following: If I specify a non-existent font for Michael> screen_font_popup and screen_font_menu value in lyxrc, lyx Michael> will crash when trying to open a menu. [...] Michael> The correct behaviour would be to use fixed font (and Michael> possibly open a popup to warn the user about it). Michael> Generally, if a font is not found, a popup window should be Michael> open. Currently, only a message is printed to standard error. Hello, I think the problem is that xforms does not behave very well with non-existent fonts. So I am not sure it is worth adding tons of code in LyX to work around that. However, we would probably accept a patch :) JMarc
Re: bug in current CVS
The problem is: I can't ;-) (Or at least haven't done so yet.) That's why I posted the picture as proof that I wasn't going round the bend. If I succeed in reproducing it, then you'll be the first to know... Angus Jürgen> I cannot reproduce this. Could you send a small example file where this Jürgen> happens? JMarc> ... a fool-proof way of reproducing it would be nice.
Re: bug in current CVS
Got it! To create this bug in a reproducible way 1 add the words "blah blah blah" to the middle of a paragraph of text. 2 Highlight them and cut them out of the paragrah. The cursor should now be flashing between two spaces: " | ". 3 Move the cursor down one row using the arrow key. The extra space disappears, text moves to fill the gap and ... Voila! Angus
Re: Changes in Win32 ports
On Tue, Mar 28, 2000 at 02:02:30PM +0200, Claus Hentschel wrote: > I've made some changes in the port to Win32 in both release 1.1.4fix1 and > 1.1.4fix2! These new ports are available at > > http://www.fh-hannover.de/mbau/tim/hentschel/lyx/index.htm > > The changes refer to missing images while previewing due to missing drive > letters for all DOS/Win32 programs called and to the misbehaviour of LyX > when deleteing error boxes after a LaTeX run (then some of your typed > charactres were deleted, too). I've seen the deleting error boxes bug after a LaTeX error on Linux, so maybe what you did for that should be applied to the CVS? ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: Did I fix the backspace bug?
Hi, On 28 Mar 2000, Jean-Marc Lasgouttes wrote: > If you are using lyx-1.1.4fix2, please try the appended patch. If it > works, I will release fix3 very soon. Please wait for fix3 until at least tomorrow. I plan a major doc update for later today! Mike [EMAIL PROTECTED]
Re: Did I fix the backspace bug?
> "mressler" == mressler <[EMAIL PROTECTED]> writes: mressler> Hi, On 28 Mar 2000, Jean-Marc Lasgouttes wrote: >> If you are using lyx-1.1.4fix2, please try the appended patch. If >> it works, I will release fix3 very soon. mressler> Please wait for fix3 until at least tomorrow. I plan a major mressler> doc update for later today! Actually, I don't know whether doc updates should go in fix* patches. In fact I have no reason why they should not go in, but I like to keep these patches small and contin bug-fixes only (and we must have some hot new stuff in releases). Anyway, you have time to come up with your modifications, I have to make sure that the fix is right. JMarc
Re: string question [was: compiling xtl?]
Hoorah! I have managed to compile the "rae" branch of CVS. Many, many thanks to Jean-Marc for his suggestions about integrating lyxstring with xtl, to Asger for passing my problems with xtl to the xtl mailing list and to Jose Orlando Pereira the xtl maintainer for his suggestions about egcs. Incidentally, I did NOT need to #include LSting.h in config.h Finally: a question. Can someone tell me how to use cvs to create a patch of the differences between my stuff and that in the "rae" branch. Something to do with cvs rdiff, but I'm damned if I can get it to work! Angus JMarc> However, I had another nasty idea about these string problems: What JMarc> about faking STL string with lyxstring when for the STL headers which JMarc> require the header? JMarc> I explain. LString.h could start like JMarc> #ifndef LSTRING_H JMarc> #define LSTRING_H JMarc> #ifndef USE_INCLUDED_STRING JMarc> #include JMarc> using std::string; JMarc> #else JMarc> #ifdef __STRING__ JMarc> #error The header has been included before LString.h JMarc> #else JMarc> #define __STRING__ JMarc> #endif JMarc> #include "support/lyxstring.h" JMarc> typedef lyxstring string; JMarc> #endif JMarc> #endif JMarc> This way, any time the real header is included, it will not JMarc> load due to the fact that __STRING__ is already defined (if other JMarc> implementation use other defines, we could provide them). The downside JMarc> is that LString.h should be included before any STL header (we could JMarc> force that by including LString.h in config.h...).
Another small bug in current CVS
Creating emphasised text in a paragraph by:
blah blah blah M-Ce is M-C_ blah blah blah
where _ indicates a space, and then viewing the dvi output
creates the following LaTeX error:
Too many }'s
...to set from Denny's output data \emph{is}}
{\selectlanguage{english}...
You've closed more groups than you opened.
Such booboos are generally harmless, so keep going.
Aside from the fact that LyX views this as an error rather
than a warning, this problem is NOT present if one types
the text normally and then emphasises it, by highlighting
it and then typing M-Ce.
Angus
CVS update problem [was: Re: Did I fix the backspace bug?]
On Tue, Mar 28, 2000 at 12:29:38PM +0200, Jean-Marc Lasgouttes wrote: > > Hello, > > I just commited a fix to cvs which fixes for me the backspace-crash > that has been plaguing LyX for some time. Go try latest cvs and tell > me what happens. I am interested to know whether your favourite way of > crashing LyX still works and whether editing still works as intended. I would happily try this but I'm getting: cvs [update aborted]: connect to anoncvs.lyx.org:2401 failed: No route to host ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: bug in current CVS
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Got it! To create this bug in a reproducible way 1 add the Angus> words "blah blah blah" to the middle of a paragraph of text. Angus> 2 Highlight them and cut them out of the paragrah. The cursor Angus> should now be flashing between two spaces: " | ". Angus> 3 Move the cursor down one row using the arrow key. The extra Angus> space disappears, text moves to fill the gap and ... I see the same indeed. Lars, this does not happen in 1.1.4fix3pre (with my patch applied). So it is probably in some code you tweaked. If you have an idea... JMarc
Re: Changes in Win32 ports
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes: Kayvan> I've seen the deleting error boxes bug after a LaTeX error on Kayvan> Linux, so maybe what you did for that should be applied to the Kayvan> CVS? I have done it locally, but cannot commit. It will be in fix3 too. JMarc
Re: Success compiling xtl! (ie, "rae" branch of cvs)
On Mon, 27 Mar 2000, Angus Leeming wrote:
> (Allan, could you confirm that PrinterParams::composite is
> meant to read from/ write to the members of PrinterParams?)
>
> Here's how to compile the src/frontends/xforms/ directory
> of the rae branch with egcs-1.1.2/gnu STL.
>
> STEP 1: Edit configure and edit lines 1854, 1855:
> - *2.91.*) CXXFLAGS="-g $lyx_opt -fno-rtti -fno-exceptions";;
> - *) CXXFLAGS="-g $lyx_opt -fno-rtti -fno-exceptions";;
> + *) CXXFLAGS="-g $lyx_opt";;
Just rerunning autogen.sh should have fixed this. I removed all the
exceptions and rtti entries in config/lyxinclude.m4 which is used by
autogen.sh to rebuild acinclude.m4 which in turn is used to build
configure.
Anytime you see a change made to configure.in or anything in config/ you
should rerun autogen.sh and reconfigure.
> STEP 2:
> configure --without-included-string
>
> STEP 3:
> make
>
> NOTE 1. The usual "-fno-rtti -fno-exceptions" causes
> compilation to fall over in FormPrint with an internal
> compiler error.
See above.
> NOTE 2. The usual (default) "configure --with-included-string"
> produces the following error:
See discussion in my response to your earlier email on this topic.
> NOTE 3. This configure option ("--without-included-string")
> will cause compilation to FAIL in the main src/ directory:
>
> g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -g -O -ansi -W -Wall
>-Wno-return-type -Wp,-MD,.deps/formula.pp -c formula.C -o formula.o
> formula.C: In method `void InsetFormula::display(bool)':
> formula.C:583: no matching function for call to `string::clear ()'
>
> Nonetheless, compilation of the src/frontends/xforms/
> directory IS possible.
Hmmm... I don't recall this happening to me. But I used 2.95.2 so maybe
the STL's are slightly different. (I got it to compile and run so it must
have worked)
> NOTE 4. Compiling FormPrint will result in LOTS of warnings:
>
> ... [snip many template-type warnings]
> ../../../src/PrinterParams.h:119: warning: initialization of non-const
> reference `int &' from rvalue `int'
> ... [snip many template-type warnings]
The template warnings are probably all signed/unsigned warnings IIRC. You
can add a few casts in the respective gcc headers to stop those.
> This can be resolved by editting PrinterParams.h, so:
[...] see comments in reply to your earlier email.
> Note, however, that I'm not sure what the effect of this change is
> because I haven't yet managed to produce an executable.
I'll have a go with my 1.1.2 installation and see if I can't get something
working.
> Moreover, I think that Allan said that the old code for the print
> dialog is still enabled, so these changes will make no difference!
That's correct, my main interest was getting something to compile. I
haven't had much time to work on this since I committed it -- I haven't
even had time to write this fortnights LDN (which will be delayed till
next week now).
I'll try to add the code to use the new implementation tonight or tomorrow
night.
> If the idea of composite() is read from / write to "target" and
> "which_pages" then clearly the write to bit of this won't work with
> the change I've made as it is. An extra couple of lines are needed to
> pass t to target, etc.
I think we'll be better off with separate read/write or fixing xtl to
support enums. Again see my reply to your earlier email.
> NOTE 5. I'm going home!
> Have a good evening,
> Angus
>
Allan. (ARRae)
Re: size of binary
On 27 Mar 2000, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Hi all, I've just noticed the size of the binary of lyx-cvs: > Angus> -rwxr-xr-x 1 aleem users 32768000 Mar 27 11:36 src/lyx* > > Angus> That's 32MB! > > I get only: > -rwxr--r-- 1 lasgoutt meval11968512 Mar 21 15:59 lyx > > But that's because I do not use the new-and-improved egcs with fancy > bloat-o-matic :) Actually it's because Angus has compiled with exceptions. These are the sizes of the compile rae branch aren't they, Angus? (exceptions are now enabled by default for that branch) In which case the answer is: Yes. Exceptions do add an awful lot of debugging info to a binary. Which is why the stripped binary's size is so much smaller. I think the record for binary size would be about 50MB when compiling with exceptions, SGI's STL, without-included-string and full debugging info. > Angus> Stripping it: -rwxr-xr-x 1 aleem users 2473984 Mar 27 11:37 > Angus> src/lyx* > > Angus> That's 2.5MB. And? Exceptions have that effect on binary size. Though the exception mechanism used by gcc makes considerably smaller binaries than the other common exception scheme -- at least that's what gcc.info says IIRC. > I get > -rwxr--r-- 1 lasgoutt meval3293184 Mar 27 14:12 lyx > > That's more than what you have, but alphas tend to have big binaries > anyway. Now try compiling with exceptions and see how big it is, JMarc. Allan. (ARRae)
Re: [Fwd: compiling xtl?]
On Mon, 27 Mar 2000, Angus Leeming wrote:
> (Jean-Marc and Allan, there are questions for you buried
> within here ;-)
>
> Many thanks for forwarding my compile problems to the xtl
> list, Asger. Jose (Orlando Pereira) got in touch and
> suggested that the problem would be trivial but that egcs
> got confused by the error message.
>
> So... I stripped down the source and went hunting. It tuned
> out that the problem WAS trivial. The static casts in
> PrinterParams::composite() produce a warning from get() and
> a horrible error from set().
>
> The following works:
> template
> void composite(Stream & stream)
> {
> + int t, wp;
> + t = static_cast(target);
> + wp = static_cast(which_pages);
You should get into the habit of declaring and defining together:
int t(static_cast(target));
or
int t = static_cast(target);
> stream
> - .simple(static_cast(target))
> + .simple(t)
> .simple(printer_name)
> .simple(file_name)
> - .simple(static_cast(which_pages)
> + .simple(wp)
> .simple(from_page)
> .simple(to_page)
> .simple(reverse_order)
> .simple(unsorted_copies)
> .simple(count_copies);
> }
The static_casts<> are needed (for gcc-2.95.2 at least) because xtl
doesn't know how to handle enums. I couldn't see a way to define
composite for an enum although it may be possible to extend xtl to support
enums -- I haven't gotten around to that yet.
Alternatively, I could ditch the enums but that is even sillier because we
use enums for all sorts of things and it's very obvious what
Target::PRINTER means as opposed to guessing what a 0 (zero) means.
> I'm not sure what the implications of this change are, however. Allan?
> If this function is meant to change target or which_pages, then it
> won't. I'm pretty hazy about just what is going on here.
The template creates code for both input and output although it's possible
to write separate implementations for input and output if need
be. Hopefully we won't need to resort to that.
> The error message that I now get is far more understandable ;-) See below.
>
> Allan, is this the LString problem you mentioned in your original post?
Yes.
> If so, Jean-Marc had a fix for this I believe, but I seem
> to have forgotten it. It was something like:
>
> #ifdef __STRING__
> #undef __STRING__
> #endif
>
> But changing the top of PrinterParams.h to...
> #ifdef __STRING__
> #undef __STRING__
> #endif
>
> #include "support/lxtl.h"
>
> ...doesn't do anything. JMarc?
If we could compile without exceptions we'd be okay. The problem is that
gcc's header has a line:
#include
which naturally enough reads gcc's idea of what string is. For now you
should be able get things running by just using:
./configure --without-included-string
I can compile --with-included-string using SGI's STL because their
header includes and I've already
written a wrapper for that along with some support in configure. We might
have to wrap in a similar manner and fortunately this should be
quite easy to do. I'll have another go at getting the quoting right for
my LYX_PATH_HEADER check in lyxinclude.m4 and then setup a
wrapper.
> Angus
>
>
>
> g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/
>-I../../../src/frontends/include -I../../.. -I../../.. -g -O -fno-rtti
>-fno-exceptions -ansi -W -Wall -Wno-return-type -Wp,-MD,.deps/FormPrint.pp -c
>FormPrint.C -o FormPrint.o
> FormPrint.C:325: warning: #warning check this works when we have working gui again
> In file included from /usr/local/egcs/include/g++/stdexcept:36,
> from ../../../src/xtl/objio.h:34,
> from ../../../src/support/lxtl.h:19,
> from ../../../src/PrinterParams.h:18,
> from FormPrint.C:14:
> /usr/local/egcs/include/g++/string:9: conflicting types for `typedef class
>basic_string,__default_alloc_template > string'
> ../../../src/LString.h:20: previous declaration as `typedef class lyxstring string'
> ../../../src/xtl/objio.h: In method `class obj_output &
>obj_output::object(Base *&, T0 *, T1 *)':
> In file included from ../../../src/support/lxtl.h:19,
> from ../../../src/PrinterParams.h:18,
> from FormPrint.C:14:
> ../../../src/xtl/objio.h:391: confused by earlier errors, bailing out
> make: *** [FormPrint.lo] Error 1
Almost there.
Allan. (ARRae)
Re: LyX CVS access problem
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | I am using the exact same settings I have always used: | | [kayvan@satyr ~/src/lyx]$ cvs update | Fatal error, aborting. | anoncvs: no such user | cvs [update aborted]: authorization failed: server anoncvs.lyx.org rejected access | [kayvan@satyr ~/src/lyx]$ | | Can someone help? No, not yet. I am fixing stuff on our servers and things will break, work and break again until I have everything in place. I'll try to get anoncvs working soon. Lgb
Re: bug in current CVS
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Angus> Got it! To create this bug in a reproducible way 1 add the | Angus> words "blah blah blah" to the middle of a paragraph of text. | | Angus> 2 Highlight them and cut them out of the paragrah. The cursor | Angus> should now be flashing between two spaces: " | ". | | Angus> 3 Move the cursor down one row using the arrow key. The extra | Angus> space disappears, text moves to fill the gap and ... | | I see the same indeed. Lars, this does not happen in 1.1.4fix3pre | (with my patch applied). So it is probably in some code you tweaked. | If you have an idea... The same behaviour without your segfault fix? Lgb
Re: Another small bug in current CVS
On Tue, Mar 28, 2000 at 05:36:06PM +0100, Angus Leeming wrote:
> Creating emphasised text in a paragraph by:
>
> blah blah blah M-Ce is M-C_ blah blah blah
>
> where _ indicates a space, and then viewing the dvi output
> creates the following LaTeX error:
>
> Aside from the fact that LyX views this as an error rather
> than a warning, this problem is NOT present if one types
> the text normally and then emphasises it, by highlighting
> it and then typing M-Ce.
>
This is my fault :(. The following patch fix (half of) the problem.
I''ll submit a full fix shortly.
Index: lyx_cb.C
===
RCS file: /home/dekel/CVS/lyx/lyx_cb.C,v
retrieving revision 1.30
retrieving revision 1.32
diff -u -p -r1.30 -r1.32
--- lyx_cb.C2000/03/26 21:27:12 1.30
+++ lyx_cb.C2000/03/28 18:57:15 1.32
@@ -2154,7 +2154,7 @@ void LangCB(string const & l)
void StyleReset()
{
- LyXFont font(LyXFont::ALL_INHERIT);
+ LyXFont font(LyXFont::ALL_INHERIT, ignore_language);
ToggleAndShow(current_view, font);
}
@@ -2691,11 +2691,9 @@ extern "C" void DocumentApplyCB(FL_OBJEC
if (!current_view->available())
return;
- if (lyxrc.rtl_support) {
- current_view->text->SetCursor(current_view->text->cursor.par,
- current_view->text->cursor.pos);
- current_view->setState();
- }
+ current_view->text->SetCursor(current_view->text->cursor.par,
+ current_view->text->cursor.pos);
+ current_view->setState();
LyXTextClassList::ClassList::size_type new_class =
fl_get_choice(fd_form_document->choice_class) - 1;
Re: [Fwd: compiling xtl?]
Ok, Allan, a final report before I go home.
I have managed to compile the "rae" branch of CVS making a
few v.small changes to do so. I can compile with lyxstring
using JMarc's suggested change to LString.h
Having compiled the branch as is, I then made four
tiny changes:
---
src/lyxfunc.C line 753:
- MenuPrint(owner->buffer());
+ owner->getDialogs()->showPrint();
src/frontends/xforms/Dialogs.C, line 17
+ dialogs_.push_back(new FormPrint(lf, this));
src/frontends/xforms/FormPrint.h:
-#ifdef __GNUG__
-#pragma interface
-#endif
(These one allows the code to link)
src/frontends/xforms/FormPrint.C, line 219
-_("Print"));
+_("Print (New)"));
(Just to prove to myself that I launch the new dialog)
---
I then ran the newly compiled executable and opened up the
print dialog. It opens fine and displays the default
settings, so geting info from PrinterParams appears Ok.
I then tried to print to file (changing the default name to
newoutput.ps). This fails, but the output to shell shows
that the name at least is passed correctly to PrinterParams:
This is dvipsk 5.58f Copyright 1986, 1994 Radical Eye Software
' TeX output 2000.03.28:2128' -> '/tmp/lyx_tmp6766aaa/lyx_bufrtmp6766aaa/newoutput.ps'
dvips: ! couldn't open PostScript file
Some bad news however. There are many messages to the
xterm of the form:
Unaligned access pid=6766 va=11fffe68a pc=1200bf904 ra=1200bf3e0 type=lds
Some work still to do, it would appear.
-
If you can tell me now to make a diff file between my
sources and those on the rae branch of cvs, I'll send you a
patch of the (trivial) changes that I've made to get this
far. (Note that this is entirely independent of the stuff I
did before. This is simply getting your stuff to run on my
machine with egcs-1.1.2 and GNU STL).
Good night all,
Angus
Bug in 1.1.5cvs
Hi
Checked the cvs 28.3. from ftp.sylvan.com. By and large a nice package.
However, it seems like lyx-1.1.5cvs of today, does not correctly
understand the bst-packages
with lyx-1.1.2. I can use
\usepackage{harvard}
nicely
Lyx 1.1.5cvs of today do not understand the useful citation command
\citeaffixed{"key-string"}{e.g.}
got error messages in LyX and could not "view-dvi" my file.
I think this is a LyX 115 error not a LaTeX error.
(Have no problems with LyX-1.1.2. Latex complies nicely the lyx 1.1.2
exported tex-file)
Do not know if the same problem occurs through lyx-1.1.3-1.1.4.
I still use lyx-1.1.2 for serious work
Best,
Staffan
Re: [Fwd: compiling xtl?]
Angus Leeming <[EMAIL PROTECTED]> writes: | src/frontends/xforms/FormPrint.h: | -#ifdef __GNUG__ | -#pragma interface | -#endif | (These one allows the code to link) In stead of that you could try to add #ifdef __GNUG__ #pragma implementation #endif to FormPrint.C unless already present. Lgb
tex2lyx
I've got a bit more faith in Andre's tex2lyx converter. Using LaTeX to
translate LaTeX isn't just a cool hack---it happens to be the best way
to read LaTeX. That is, we know that LaTeX won't have any trouble reading
LaTeX input, even if it isn't "well-behaved".
What that means is that you won't be struggling with a lot of the
disadvantages I mentioned in my previous email.
(1) we know that optional arguments and commands without braces will be
handled OK.
(2) If you can get rid of the Perl wrapper, users won't need Perl, LeX, or
anything. We know they've got LaTeX. (Even if you can't get rid of it, it's
still significantly smaller.)
(3) If we get some LaTeX gurus to work on it, unknown stuff can probably be
perfectly isolated in TeX mode blocks (um, insets).
(4) We won't have any of that "I can't help you because I don't know Perl"
whining. :)
I think that badly-behaved LaTeX may still be your downfall, though. For
example, it looks like you translate {[} into a bracket. But what about a
plain [, which is probably how a lot of people will write it?
Anyway, this seems like an easier method than ltx2x, and one that will get
results sooner.
I'm still wondering, though. When exactly did we all decide reLyX should
retire?
-Amir
ltx2x
Kayvan said:
> Doing some searches on the net, I found a very interesting piece of
> software at http://www.nist.gov/sc4/editing/latex/programs/ltx2x/
>
> I am thinking of using it as the basis for a C-based reLyX replacement.
>
> Amir, can you take a look and tell me what you think?
Wow. It's pretty impressive.
Did you notice btw that it's on CTAN (tex-archive/support/ltx2x/) and that
it's now version 0.92?
My first reaction was of course "how dare you try to replace reLyX?!" Then
I realized that I was just thinking that because I put so much effort into
it. Considering that LyX 1.0 was initially supposed to make reLyX obsolete,
I can't really complain if a better latex converter comes along.
Advantages:
(1) It's in C, so people don't need to have Perl and I would think
it could even be included in the LyX code. (I assume you could distribute
the C rather than the lex etc. files. Otherwise, file this in
disadvantages.)
(2) It's under the LLPL, which I assume doesn't hurt the GPL? (If it does,
file this under disadvantages.)
(3) It can handle a whole lot of stuff. And I suspect that a lot more work
went into it than into the v0.01 Text::TeX module that's at the heart of
reLyX. (I may have put a lot of work into reLyX, but I only tinkered with
Text::TeX.)
That said, there are (at least) a couple problems with using it.
(1) One reason people didn't want to help work on reLyX was that they didn't
know Perl. How many people do you think will know lex, yacc, express-a, and
the ltx2x command table language?
(2) If you look at the ltx2x limitations, you'll see that e.g. it can't
handle x^2 (it requires you to write x^{2}) or {\em foo} (it requires
\emph{foo}). Those are, of course, two of the more popular LaTeX functions
(although hopefully people will stop using \em eventually, I wouldn't hold
my breath). That means that --- unless ltx2x overcomes these limitations at
some point --- you'll still need to use CleanTeX.pl, but that means
distributing reLyX AND something else!
(3) ltx2x has the same problem of not handling optional arguments correctly
that reLyX has, although it may be to a lesser extent.
(4) It seems like ltx2x may have some issues with \newcommands, though
probably not to the same extent that reLyX does.
(5) related to #2-4, I don't know how active development on ltx2x is. OTOH, it
may be powerful enough currently to handle just about everything you want
to.
(6) If you decide to do this, you'll be starting almost from scratch ---
you'll be able to use some of the reLyX output ideas, and the
syntax.defaults file e.g. says how many arguments each command takes. But
nonetheless you're going to have to write code-handling for every single
command. Which, trust me, is a lot of work. In addition, you are guaranteed
to run into situations where the way that ltx2x looks at things isn't the
way that LyX does, which will require kludging.
I hope I wasn't *too* biased. But to return to my knee-jerk reaction for
just a moment: why exactly do you want to replace reLyX rather than fix it?
-Amir
Re: tex2lyx
Amir Karger <[EMAIL PROTECTED]> writes: | I'm still wondering, though. When exactly did we all decide reLyX should | retire? We didn't. Lgb
Re: [Fwd: compiling xtl?]
On 29 Mar 2000, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > > | src/frontends/xforms/FormPrint.h: > | -#ifdef __GNUG__ > | -#pragma interface > | -#endif > | (These one allows the code to link) > > In stead of that you could try to add > #ifdef __GNUG__ > #pragma implementation > #endif > > to FormPrint.C unless already present. It's already there. I managed to compile last night with 1.1.2 using SGI's STL without complaints. I do get the same warnings/errors as Angus when using gcc's STL and lyxstring. Still haven't gotten around to doing any fixing though. Should have a spare hour tonight. Allan. (ARRae)
Re: ltx2x
On Tue, Mar 28, 2000 at 04:30:04PM -0500, Amir Karger wrote: > Kayvan said: > > Doing some searches on the net, I found a very interesting piece of > > software at http://www.nist.gov/sc4/editing/latex/programs/ltx2x/ > > > > I am thinking of using it as the basis for a C-based reLyX replacement. > > > > Amir, can you take a look and tell me what you think? > > Wow. It's pretty impressive. > > Did you notice btw that it's on CTAN (tex-archive/support/ltx2x/) and that > it's now version 0.92? Cool. No, I hadn't noticed that. > My first reaction was of course "how dare you try to replace reLyX?!" Then > I realized that I was just thinking that because I put so much effort into > it. Considering that LyX 1.0 was initially supposed to make reLyX obsolete, > I can't really complain if a better latex converter comes along. Just to clarify and soothe any inadvertently ruffled feathers: I'm just thinking long-term here. I'm still fixing the perl based reLyX bugs. > Advantages: > > (1) It's in C, so people don't need to have Perl and I would think > it could even be included in the LyX code. (I assume you could distribute > the C rather than the lex etc. files. Otherwise, file this in > disadvantages.) > > (2) It's under the LLPL, which I assume doesn't hurt the GPL? (If it does, > file this under disadvantages.) > > (3) It can handle a whole lot of stuff. And I suspect that a lot more work > went into it than into the v0.01 Text::TeX module that's at the heart of > reLyX. (I may have put a lot of work into reLyX, but I only tinkered with > Text::TeX.) *nod* I'm just playing around with it, trying to figure out if it's worth anything. > That said, there are (at least) a couple problems with using it. [...] > > [... List of comments deleted ...] > > I hope I wasn't *too* biased. But to return to my knee-jerk reaction for > just a moment: why exactly do you want to replace reLyX rather than fix it? Is it Friday yet? I don't want to replace reLyX, I was idly wandering the net (after a hairy session or perl debugging) and thinking about long-term options. I think it's good to look at how other people have handled the same problems. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: tex2lyx
On Tue, Mar 28, 2000 at 04:58:39PM -0500, Amir Karger wrote: > I've got a bit more faith in Andre's tex2lyx converter. Using LaTeX to > translate LaTeX isn't just a cool hack---it happens to be the best way > to read LaTeX. That is, we know that LaTeX won't have any trouble reading > LaTeX input, even if it isn't "well-behaved". [...] > > Anyway, this seems like an easier method than ltx2x, and one that will get > results sooner. > > I'm still wondering, though. When exactly did we all decide reLyX should > retire? We didn't. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: Did I fix the backspace bug?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Hello, | | I just commited a fix to cvs which fixes for me the backspace-crash | that has been plaguing LyX for some time. Go try latest cvs and tell | me what happens. I am interested to know whether your favourite way of | crashing LyX still works and whether editing still works as | intended. Have purify stopped complaining? Lgb
Re: Did I fix the backspace bug?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Hello, | | I just commited a fix to cvs which fixes for me the backspace-crash | that has been plaguing LyX for some time. Go try latest cvs and tell | me what happens. I am interested to know whether your favourite way of | crashing LyX still works and whether editing still works as intended. | | If you are using lyx-1.1.4fix2, please try the appended patch. If it | works, I will release fix3 very soon. btw. I see this bug: '|' is cursor as usual. g | g press backspace and you get: g|g not sure if that is related. Anyway I will look at it. Lgb
Re: Did I fix the backspace bug?
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> Hello, | | I just commited a fix to cvs which fixes for me the Lars> backspace-crash | that has been plaguing LyX for some time. Go Lars> try latest cvs and tell | me what happens. I am interested to Lars> know whether your favourite way of | crashing LyX still works Lars> and whether editing still works as | intended. Lars> Have purify stopped complaining? Yes. JMarc
Re: Did I fix the backspace bug?
On 29-Mar-2000 Lars Gullik Bjønnes wrote: > btw. I see this bug: > > '|' is cursor as usual. > >g | g > > press backspace and you get: > >g|g > > not sure if that is related. Anyway I will look at it. #:O) you noticed this? That's the stuff I tell you all the time (and I fixed it here) and you told me this was made by you intentionally ;) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug History repeats itself only if one does not listen the first time. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: tex2lyx
> I think that badly-behaved LaTeX may still be your downfall, though. For
> example, it looks like you translate {[} into a bracket. But what about a
> plain [, which is probably how a lot of people will write it?
Erm... did I mentioned that is wasn't finished and that I didn't want to
show it to you in the first place? This is a bag full of hacks and I
know it ;-)
> I'm still wondering, though. When exactly did we all decide reLyX should
> retire?
I did not yet. In fact, I see my attempt as a complementary way of
translating .tex to .lyx. Once tex2lyx is useable I could even imagine
two import modes until we figured out which one is better in *all* cases.
Andre'
--
It'll take a long time to eat 63.000 peanuts.
André Pönitz . [EMAIL PROTECTED]
