Jean-Marc, you're a superstar!
My macros are no longer centred and they work.
I had used egcs (1.1.2) to compile lyx. Re-compiling math_iter.o without
optimisation means that the code no longer crashes. Incidentally, this bug used
to be documented in the INSTALL file. Since it still exists, I think you should
mention this work-around in there again.
Now I have a new macro bug to report, albeit much smaller.
Consider the macro:
\begin_inset FormulaMacro
\newcommand{\domain}[1]{\Omega _{#1 }}
\end_inset
I'd like it to be
\newcommand{\domain}[1]{\Omega _{\mathrm{ #1 }}}
Ie, I'd like the subscript to be upright. (Some journals have this as a style
requirement.)
In fact, in an ideal world:
\newcommand{\domain}[1]{\Omega _{\,\!_{\mathrm{ #1 }}}}
I'd like to lower the subscript a little. This is my hacked way of doing so
Lyx won't export either of these. (It won't save it. The tex file it creates
doesn't contain it. Nada.) Why not?? I have no problems if I put the
\newcommand at the top of the page.
Any and all insights welcome!
Angus
Incidentally:
JMarc> Any help in solving this (math_iter.C optimisation) problem would be very
JMarc> welcome.
I'm a competent coder but my C++ is definitely of the hacker variety.
Nonetheless, since I have the "perfect" environment to investigate this bug,
point me in the right direction and I'll give it a go.
Angus
> "JMarc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I can define macros and use them to create equations quickly.
Angus> However, when I come to create output using view dvi, latex
Angus> complains that these control sequences are unknown. The only
Angus> remedy I've found is to edit the lyx file by hand, cut out the
Angus> macros, and reinsert them in the latex preamble as straight
Angus> 'newcommands'. In this case, I can't use them within lyx to
Angus> create my equations because lyx doesn't recognise that they
Angus> need arguments.
Angus> I attach two files to illustrate what I mean:
JMarc> You have centered the paragraph which contains the macros, meaning
JMarc> that they are defined as
JMarc> {\centering
JMarc> \newcommand...
JMarc> \newcommand...
JMarc> \par}
JMarc> The effect is that the definitions are lost when the last } is
JMarc> encountered. Just setting the justification of the paragraph
JMarc> containing the macros to Block (as it is by default) solves the
JMarc> problem.
JMarc> I do not know how we could avoid that... but we should, ideally.
Angus> good_tex.lyx, everything appears to work correctly BECAUSE
Angus> lyx's macros are defined for all documents. Surely, macros are
Angus> document specific!!!
JMarc> Yes, this is something that's supposed to be fixed later: make the
JMarc> macros document-specific. Now, it has the advantage that, if you
JMarc> define a macro in your main document and include other documents
JMarc> therein, the macros will be accessible on all documents.
Angus> 2. crashes -------- both 1.04 and 1.1.2 crash A LOT. One
Angus> particular instance concerns macros.
Angus> Running a non-stripped version of 1.1.2 under gdb on a DEC
Angus> Alpha running Digital Unix 3.2
JMarc> A guess: are you compiling with egcs? Which version? I am personnally
JMarc> developping LyX on Digital Unix 4.0f (was 3.2 not so long ago) and it
JMarc> works fine, when compiled with both gcc 2.8.1 and dec cxx 6.1.
JMarc> However, we've had plenty of bug reports with egcs, and a particular
JMarc> bug of egcs 1.x (bad intrisic memcpy()) is even worked around in the
JMarc> code. My guess is that some other egcs bugs exist (there are crashes
JMarc> with gcc 2.95.x too), but I am not competent enough to catch them.
JMarc> As far as I know the problem is in math_iter.C, where the data is
JMarc> stored in an array of bytes. This means that at times you have to copy
JMarc> pointers to non-aligned locations, and egcs breaks on that. The break
JMarc> that you see is probably a consequence of reading bad data. You can
JMarc> try to compile math_iter.C without optimization (or with
JMarc> -fno-builtins) and see whether this helps.
JMarc> Any help in solving this problem would be very welcome.
JMarc> Now, if you do not use egcs/gcc2.95, forget all that I said :)
