Hi all, I'm Steve Litt, a regular on the user's list. Since 2001, all my books have been written in LyX.
I'm not a LyX developer. Believe me, you guys wouldn't want to work with my C++ code. What brings me here is an interest, from a user point of view, in the upcoming XML native format. This interest comes from the fact that I regularly create LyX native format docs programmatically, and regularly edit LyX docs in Vim when I don't know how to accomplish it within LyX itself. Because I strongly believe that XML is difficult to casually parse, I'd like to do the following: 1) Document your new XML format. Not only its specification, but the reasons and philosophies behind it. I think this will be of use to other LyX "power users" who, like myself, sometime create/change LyX content without the LyX front end. 2) During initial design, review the new XML format from a power user point of view, and point out areas where it makes the power user's job difficult. Redundancy would be one example. If the paragraphs were in one place, and the number of paragraphs were in another, changing one would require changing the other, and that's not obvious upon casual observation of the native format file. 3) Create LyX-XML to YAML and YAML to LyX-XML utilities, so that power users can do their parsing in easy to parse YAML and then convert it back to LyX-XML. This decouples the needs of the LyX developers from the needs of power users. I'll write these utilities first in Ruby for the oldest reason in the world -- it's easy. Later I can probably rewrite them in C or C++, depending on what XML parsers are available. I'm the maintainer of the VimOutliner to LyX script, so it's important to me that the script continue to work after the transition to XML. Also, many times I find it a big timesaver to edit LyX with Vim to do my work. These are the reasons I'd like to do these three things. Thanks SteveT Steve Litt Recession Relief Package http://www.recession-relief.US
