On 01/13/2010 04:13 PM, Steve Litt wrote:
On Wednesday 13 January 2010 13:36:09 José Matos wrote:
Hi all,
I would like to start working on the goal of having lyx with an xml file
format.
Once again I'd like to say that if not done exactly right, XMLizing LyX native
format will disenfranchise the significant minority of users who either edit
native LyX by hand, read it with scripts, or write it with scripts, or
combinations thereof.
We are, as we have said before, very aware of this. Many of us write and
use such scripts all the time.
Note, by the way, that the new "advanced find and replace" feature is
going to make sure scripts a lot less necessary.
I can tell you that already, before XML, the native format of LyX 1.6.4 is
already much harder to read and write with scripts than the 1.5.x and 1.4.x
were.
This is surprising, and I'm not sure why it would be. The file format
did not change significantly in ways that should affect this.
In a last-year's thread XML and direct manipulation of LyX files it was
pointed out that LyX native format could be written in such a way as to make
script parsing/writing easier -- presumably by inserting newlines. However, my
work with 1.6.x format tells me newlines aren't necessarily the answer, as the
following code shows:
[snip]
What makes this hard to read are all the newlines after periods. I am
not sure why we do this, but I will try to find out.
Especially difficult are nested inset tags of different types, necessitating
maintaining a stack to deduce which end ends which tag, because the end tag
has no type to remind you. Perhaps a comment after end tags for insets would
help with hand parsing, although of course that would increase the size of the
file.
But there have always been such nested tags, and I doubt there's any
reliable way to deal with them, other than a stack. The comment would
help make sure you weren't completely off base, but wouldn't guarantee
you had the right inset, unless they're all numbered or something, which
seems excessive.
It would be great if start tags would be entirely on one line, regardless of
their length. That makes grep type activities much easier. Another help would
be with insets if the properties always occurred in the same order (probably
type right after the<inset.
I expect they will always be in the same order, since that is the
easiest way to code things. I don't think everything will always be on
one line, because some people like the 80 character limit, precisely to
be able to view things nicely in vim, etc.
rh
