Pavel Sanda ha scritto:
i don't believe reimporting-back stuff is doable 100% correct
so this does not look like good direction.
I know how hard is to make tex2lyx import something correctly,
or at least how expected. Here we would "play at home field", i.e.,
we would import something that has just been exported and
manipulated in a controlled/known way.
Probably not all combinations of options actually make entirely
sense, or are easy to implement.
while i played with this yesterday i come to understand that except
some bugfixing there are still features disabled and not implemented,
so i'm bit pesimistic that this will become part of 1.6.x,
moreover that you don't have time on it...
I can work at it in my spare time, which is not much, and if
people show interest in the feature, this gets a raise in motivation.
In the short time, I can focus on fixing the search capability, delaying
GUI interaction issues to later (these are the most time consuming
for me, because the data flow between internal LyX classes looks
to me like very complex) or others (I guess a core LyX developer
could do that in a much shorter time).
to me this complexity is not critical and the other approaches
seems to be lot of coding work (esp.1) without some substatinal
improvement.
Well, it's normal that one tries the least-effort way for the proof
of concept. However, for example, the same text-based or latex-based
export capability seems to me a reuse of some visitor pattern that
could instead be implemented just once (here I mean some generic
mechanism for visiting the entire text graph with all involved insets,
then one could have the text-based visitor, the latex-based visitor,
etc...). Also, whenever you save/serialize you need a further visit
made by a lyx-based visitor (or an xml-based one in the future).
I refer to the code as ~1 year ago, don't know about it now.
note that wiki doesn't need any special permission for changes...
Ok, I'll consider this. Bye,
T.
