Hi,
probably I'm repeating myself, but AFAICS tolerating future file-formats
in lyx would not be a bad idea.
In the last editing of a paper in these days, I had to instruct a PhD
student using an old Debian with LyX 1.6 to:
1) open the .lyx file with an editor
2) replace the 413 with 345 "magic number" at the beginning
3) edit the file with his system-wide editor.
The above was needed of course due to my laziness in exporting to a 1.6
compliant format all the time. I was forgetting that, and the file was
getting converted to the 2.0.0 format all the time.
Also, with the last multi-extension patch (and the zipped=native flag
for dia), the development version of LyX upgrades my RC file, then my
system-wide LyX *refuses to start*!
In both cases, I can see a minor change in what LyX expects to see
causing a major failure in LyX -- the impossibility to start it again or
loading a file.
AFAICS, it would not be bad to have an option with which LyX tries to
ignore what is not understood in future file-formats, and simply goes on
trying to execute anyway (e.g., --keep-going a'la make). For example, in
the RC file format case, LyX could ignore those lines (and
formats/converters) that fail to be parsed. This would allow a normal
user to reconfigure and restore a working environment.
Bye,
T.
