>>>>> "Duncan" == Duncan Simpson <[EMAIL PROTECTED]> writes:
Duncan> I am not sure whether this bug is a reLyX or mathed bug
Duncan> (argiably both I guess). mathed segfaults in mathed_parse when
Duncan> attempting t o cope with
[snip]
reLyX and mathed are certainly not designed to cope with plain TeX
constructs. The rule of thumb (there are exceptions) is that, if a
command is not described in the LaTeX book, it will not be handled
correctly by reLyX and/or mathed. Mathed, in particular, is very fussy
about syntax: it accepts the simple LaTeX syntax like \foo{1}{2}, but
certainly not the weirder things like
\hbox to \wd0{foo}
Even \over is out of scope.
Duncan> granted this is not the sort of thing most formulae feature
Duncan> but it is a valid combination of plain TeX and LaTeX (the
Duncan> \Large, etc are I think LaTeX and valign is definately plain
Duncan> TeX). I guess mathed should know that halign, valign and stuff
Duncan> like that should be left alone for the forseeable future.
The problem is that, since mathed tries to parse formulas directly, it
does not have the notion of raw TeX stuff which should be left alone,
as the rest of LyX has. I'm not sure there is a way to solve your
problem in the current state of things. reLyX could probably output a
warning on unsupported and dangerous plain TeX constructs, though.
Duncan> reLyX also tends to make a big mess of multiple line amcros
Duncan> defined using \def (like \newcommand but potentially *much*
Duncan> hairer and a lot less typing). Putting gratitous blank lines
Duncan> in the way the TeX to LyX to TeX process breaks these badly. A
Duncan> particular sample is
Duncan> \def\sgp{\vcenter{\hbox{
Duncan> \valign{\vfil\hbox{$\bsn##$}\vfil&\vfil\hbox{$\bsn##$}\cr
Duncan> I_{k'} & M' \cr \noalign{\hskip0.5ex}
Duncan> \omit\span\omit\vfil\hbox{\Large $\boldsymbol 0$}\vfil\cr }
Duncan> }}}
To tell you the truth, I would have been amazed if such a thing
worked. Math support is a LaTeX-only zone.
JMarc
