I'm glad to receive so many feedbacks for my patch :-)
And here I have to tell you some of my thoughts:
1. I made this patch is because I need it. I have to
convert .tex files including those features, and
convert between .tex and .lyx back and forth. I met
these problems addressed in the patch, and lucky
I'm a programmer, so I can make a patch to improve
it: that's one of the most important reason that we
support open source. Certainly the patch has a _lot_
of problems, as it's just assumed to be used by myself.
And your feedbacks will certainly be considered to
make better version. It's absolutely OK for me whether
this patch is accepted or not, because I can always
compile my patched version, and I have several other
patches for lyx. I put it here just in case someone
else may need it, and get some idea how this problem
affects others.
2. I also dislike current tex2lyx structure. But I also
dislike the idea of python script. If let me make the
choice, I will choose flex, or flex+bison. Flex syntax
is extremely suitable for parsers, for both programming
and maintenance. I don't see any advantage of python
at this point. Certainly, flex in it's original state
is not suitable to be used to develop tex2lyx. We need
several distict features that are not supported by
original flex. But we can make our improved flex.
And it's not difficult at all. I believe we just need
to have a new template for the code generation. I have
used flex as this way, and I have a template that is
able to support true C++ lexer, abstract input/output,
etc. If needed, I can distribute my work to this community
and make some improvements to satisfy the tex2lyx needs.
And, another benefit of flex is speed. I assure it will
be much faster than current C++ code.
3. I want the integration of tex2lyx with lyx a lot. Indeed
I'm working on a patch to enable relyx upon paste. I posted
one patch several weeks ago to enable relyx \cite{...}. If
the integration is achieved, then this part of work is much
easier. And, the integration is another support for using
flex to develop tex2lyx.
4. As of incorrect file format, my idea is, if "tex2lyx+lyx2lyx"
produces correct output, we can think it's OK. Because we always
go "tex2lyx+lyx2lyx". If needed, we can call lyx2lyx in tex2lyx,
so that the final output of tex2lyx is absolutely valid. And in
this way, the encoding problem is also solved.
5. Even though we have new implementation of tex2lyx planned,
we can still make small imporvements on current tex2lyx.
I don't care whether it will get lost, as it just costs
me one or two days. But it will save me significantly
on my work before the new implementation is available.
As I said above, I need these features badly. And such
work will give us the information of what kind of features
are useful and should be supported in new implementation.
So, I think completely halting the development of tex2lyx
is incorrect. We can still make small improvements.
Above are IMHO certainly :-) And now our major problem
is to decide a direction of future tex2lyx ASAP.
We now have severaly completely different proposals.
How can we make the decision?
Regards,
Hangzai
