> I've put a patch under
>
> http://mathematik.htwm.de/Software/LyX/index.html.en
>
> that uses ostreams instead of FILEs for output and generally cleans up a
> bit (in my eyes).
I recommended all developers to check this stuff out. It's good work.
> It's a bit longish and it is only tested with my own stuff, so I do not
> want do throw it an anybody who is reading the list.
Good move.
> Since I have never used a few of the functions I had to change
> I'd like to ask you to apply it and test it with your own docs.
> Any comment is welcome.
I didn't try it, but read most of it, fast.
It's impressing work you have done there. Congratulations.
I recommend that Lgb includes this as the next mayor clean-up
item of LyX-devel, after we have had a new release with the
latest bug-fixes and clean-ups (when is that coming, Lgb?).
Then, we should have a release with the new load/save code,
and a relatively long period of testing so that all bugs are
ironed out.
One important comment before it's ready for inclusion though:
The error handling is insufficient.
Yes, I realize that the old code didn't exactly do a great job
of handling errors, but a rewrite should at least not be worse.
I noticed that the code in buffer.C does not do any error checking
at all, after we have saved a document. That's no good. Ideally,
it should do error handling all the time... What good are the
autosave and emergency save routines if LyX can not even detect
out-of-space on the disk and won't complain when the user
specifically asks for a save?
Regarding testing: It's always a good idea to test stuff like
this with the documentation that is included with LyX, because
those are long and complex documents. Especially the User Guide
is a fine stress-test since that uses maybe 90% of all LyX
features.
So, load the User Guide, and save it as user1.lyx.
Then, load user1.lyx and save it as user2.lyx.
Now, do a "diff -u user1.lyx user2.lyx" and it should come
up empty. If not, you have certainly found a bug.
Also, do a diff with the original version of the User guide,
and manually inspect all differences. You should know your
code, and should be able to decide if things are ok. If the
diff is huge, you will probably notice why, and maybe that will
motivate you to redo some of the work to get it closer to the
original. That is always a good idea, because the LyX format
is also used in several external tools.
However, disregarding changes that should be ok, this technique
can at least point you in the direction of finding bugs.
Repeat the exercise with some of the complicated Example
documents that relies on special features, such as the
tables document, one that uses color, etc.
In this way, it should be managable to get pretty good
coverage of the new code.
Once again, congratulations on the great job! It must have
taken quite a while for you to do this, and I'm glad to see
that you took our advice: Just grab an area, and then attack
it. I would not have recommended that you grabbed this area
as the first thing, but I don't complain that you did, knowing
that it's a huge task ;-)
And hopefully, it has given you more knowledge about how LyX
works, and with that, it will be easier for you to begin a new
clean-up project.
Welcome aboard!
Asger
