Steve Litt schrieb:
Hi all,
I just solved two very difficult LyX problems using Vim, and it reminded me just
how lucky we are that the current LyX native format is easily readable and
parsable by a normally intelligent human.
In the first case, LyX would crash about 3 seconds after opening a document in
1.6.3. For various reasons I suspected it was the overly large .eps cover art,
but I encountered a buried shovel. If only I could get LyX to work, I could
change the cover art, and if only I could change the cover art, I could get
LyX to work. Vim to the rescue: I changed cover.eps to cover.pdf to work
around the problem (which I suspect is a LyX ungraceful handling of a too
large graphic).
In the second case, I had an indexing problem preventing making the PDF. Using
diagnostics like the ilg, ind and idx files, I narrowed it down to five possible
culprit index entries. I got it down to one error, but the .ind file was
showing a backslash that didn't exist in the LyX index entry. When I opened
the LyX file in Vim, the problem stuck out like a sore thumb -- there was an
extra inset and some other garbage within the index structure. I removed it
with Vim and bang, the document compiled perfectly to PDF.
There have been a lot of discussions about changing the LyX native formula.
I'd like to ask that whatever the new format turns out to be, it be at least
as easy for a normal intelligence human to manually edit, parse and modify as
the current format.
XML has been discussed, and the point has been made that if XML is done with
an eye toward manual parsing and editing, it can be as easy to parse and edit
in Vim as the current native format. While that's obviously true, we all know
that from a human parsing viewpoint, XML can quickly get out of control. One
look at any OpenOffice file confirms this. XML has the capability to make one
paragraph depend on several different XML subtrees. If authored that way, for
all practical purposes human manual parsability and editability is destroyed.
Also, the XML spec itself does not recognize lines, so it would be up to the
LyX tools to properly assign lines to nodes and vice versa. Otherwise it would
be impossible to write LyX creation and modification scripts, at least without
a big, ugly XML parser.
I'm pretty sure all the current developers understand all this because you
regularly tweak LyX from editors yourselves. I am concerned, however, that
future LyX developers will say "Hey, LyX is XML and to do our jobs correctly
we need to just worry about valid XML, not linefeeds. On that day, a great
deal of user power is lost.
So, as usual, I"m pleading that as you decide on future native formats, you
make the new formats as human parsable and editable as the current version.
Thanks
SteveT
Hi LyX developpers,
I would like to strongly support Steve's point of view !
Quite often I have to create documents which contain mostly images and
nearly no text at all.
So I put in one of the images manually using the GUI, give it a look and
the rest is done using gvim and/or bash scripting and the like.
For me this is a great gain in productivity compared to the inclusion of
maybe 80 images via the GUI.
And this procedure is possible exactly because the actual LyX internal
format is very readable (even rather suggestive ;-)
So, me too I would like to beg you all:
Keep this in mind when deciding on any change of the internal format.
For the rest LyX is THE mosdt important tool for all my work with a
computer, working (still at 66) as management consultant.
Best regards
Hellmut
--
Dr. Hellmut Weber m...@hellmutweber.de
Degenfeldstraße 2 tel +49-89-3081172
D-80803 München-Schwabing mobil +49-172-8450321
please: No DOCs, no PPTs. why: tinyurl.com/cbgq
