Steve Litt wrote:
On Thursday 14 January 2010 09:13:04 Abdelrazak Younes wrote:
rgheck wrote:
On 01/13/2010 01:36 PM, José Matos wrote:
- how to proceed in the mean time?
+ using an iterative approach we will have a file that will be
xml-ized by
parts
I think the incremental approach will actually be much less intrusive
than it might at first seem, and some of it, not necessarily all,
could perhaps be done starting now, even if we were in feature freeze.
I've done major changes to the LyX-file representation of certain
insets---e.g., the entire InsetCommand hierarchy---and it's actually
quite painless. You change the read routine; you change the write
routine; you write some lyx2lyx; you are done.
The real question I have is whether the incremental approach, though I
have suggested it myself, is actually workable. I was just thinking,
for example, how easy it would be to change the format of
InsetCommand-type insets to XML, and that maybe I'd make a patch, just
to prove the point.
I think the incremental apprach is the best. We could start with the
InsetCommand right now and then do the Paragraph and Paragraph
parameter. Then would come InsetText, InsetFloat... BufferParam can be
done easily as well.
But then I thought: How will these XML insets be parsed? There's a
whole ton of code in InsetTabular that does XML reading and writing,
since the file format of InsetTabular is at least XML-like, if not
true XML. Perhaps that could be moved to support/ and used in the
interim. Or can we use an XML parser just to parse the parts that have
been converted to XML, once we find them? Anyway, I'm not clear about
this. Maybe the first suggestion, of moving some custom code to
support/, makes the most sense. Then when we have a real XML format,
we can get a real parser.
I completely agree. Let's just change our parser incrementally for now
and when we're fully XML we will experiment switching to another parser.
Hey guys -- as long as you're writing your own parser, how bout releasing your
parser as a standalone command or something like that. In that way, for each
release, guys like me can use your parser to read native LyX into a DOM
hierarchy or SAX the thing or write it to yaml or whatever, and then if you
publish your writer standalone, we can write it back with that stuff. You've
already written the code, it's just a matter of releasing it separately with a
VERY simple interface so we can use it in shellscripts or batch files or
whatever?
Are you aware that you can already use LyX in script? The export
argument '-e' does not launch the GUI at all.
The parser code is not as easy as you might think. Each inset reads its
content itself. But sure we could recompile LyX with everything that is
not in src/frontend/ and you'll get the command line tool that you want.
But as plain LyX is already able to do that, there is not much incentive
to do this.
Abdel.
