Text saving broken

[Ganesh Paramasivam]

While coding change tracking, I had assumed that changeTracker is
always available in KoTextWriter. Looks like this assumption is not
true. Wouldn't it be simpler to just create a dummy changeTracker (in
KoTextWriter's constructor) to fix this problem.

> @Ganesh : I don't know the change tracking specification, but I really don't
> like the way the code had to be modified to support it. Is there no way to have
> it in a less mixed-in way ? I mean, right now, you can't tell between the
> classical text related calls and the calls for change tracking.

I'm assuming that you are talking about openTagRegion() and closeTagRegion().
openTagRegion and closeTagRegion are not necessarily change-tracking
code. Think of these functions as a glorified startElement() and
endElement() respectively i.e startElement() and endElement() wrappers
that also check for changes and automatically writes out the requisite
markup for these changes.

And yes, it would have been nice to not add these two functions but I
couldn't think of any other way of implementing this new spec.

> messy and dirty enough... Moreover, do unit tests only cover the case where
> change tracking is enabled ? In any case, there is a real issue since the
> regressions I fixed here are major and should have been spotted far sooner...
> (I'll try to find some ways to improve our unit testing in that area anyway).

The TestChangeTracking is meant to be a set of unit-test cases to
check loading and saving of documents containing change-tracking
markup. I do agree that these regressions should have been caught by
unit-tests. But I'm not sure whether those unit tests should go into
TestChangeTracking.

> But, for instance, you often check a save format, between deltaxml and odf 1.2 :
> what are the differences ? Why are both needed ?
> If you don't mind, a short explanation email would be helpful (or an IRC session
> if you prefer...)

Will catch you over IRC later today or tomorrow to explain this.

Thanks,
Ganesh