Uwe Stöhr wrote:
>> No it was not. What you did was detecting eLyXer but this is not
necessary
>> when it is integrated.
>
> which we haven't agreed upon
Am I blind?:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg150471.html
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg150473.html
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg150476.html
None of them had really looked at the program. What Pavel says in the
next bit is absolutely right. Jurgen said he thought lyx2lyx integration
would be good, and JMarc said he was "in general" in favor of it but
hadn't looked at the code. So those are hardly green lights.
I'm not sure about Abdel, but he's been kind of busy with other things.
> except Abdel i don't remember
> any other clear statement about proper inclusion now. JMarc wanted
to have
> lyx2lyx
> integration, Juergen also wanted the integration with eg lyx2lyx,
but havent
> said anything about the inclusion into our sources. so where you get
this idea?
I don't understand the concerns. Why can the code not be in our SVN,
that makes it so much easier to work on eLyXer (lyx2html) to get the
lyx2lyx integration we need?
I don't myself understand what integration is wanted. Can't elyxer just
check the file format and then run lyx2lyx itself if it has to do so? Or
we can define the converter so that we first run lyx2lyx to produce a
format elyxer likes, then run it on that. I don't see that any more
integration than that is even possible. Let alone desirable.
> in the begining i thought myself we can do it, but started to change
my mind
> after Richard's argumentation, which brought the whole thread into
the new
> light - it may even happen that we will have completely different
html output
> strategy.
>
> moreover Richard and later even me checked the output on yet
untested documents
> and brought the questions mainly about math support, which was
insufficient.
> i can't accept the claim that elyxer is in a better state than the
other
> converters (yet).
My problem with the discussion in this thread is that it focuses on
the current state of eLyXer. But why is that important? eLyXer is not
yet ready for branch of course, but lets integrate it in trunk and
make it better. Before we release LyX 2.0 we can decide if eLyXer is
ready to be shipped together with LyX 2.0 or we disable it by changing
a few lines in configure.py.
Now I'm the one who doesn't see the advantage. And here's a reason not
to do it: If we put it in trunk, then we have to give commit rights to
anyone who wants to work on elyxer. Why should we do that? Why not just
leave it where it is?
And besides, the discussion has NOT just been about the current state of
elyxer. What emerged, and so far as I can tell Alex just agreed, is that
many of the things I was complaining elyxer can't do it will NEVER do,
both because of what he intends the program to be (simple, one-pass,
etc) and for reasons of principle (e.g., custom style can't be handled
without reading the LaTeX).
But the main reason not to integrate elyxer is that we're likely to have
"built in" HTML output for 2.0.
rh
