Hi Martin and Paul,
> > - RMS adds "GNU/" to all occurrences of "Linux", and > > - ESR goes back through and deletes them. > > > > At edit time, all of the deleted content exists inside the piece > > table, but by design none of it gets exported to the file format. > > Off the cuff, I don't see a trivial robust change to the file format > > which will handle this gracefully. ... > > For revision marks to work well, we need to handle all three of the > > following style of changes: insert, change, and delete. The first > > is easy, the last is hard, and the second can be expressed as a > > combination of the other two. > > I was thinking we could use our change records as used by the undo > code for this. They would needed to be XML-ized but we should do > something like this anyway to display undo "tooltips". ie Put mouse > over the undo button and see the last five operations. I think you are going the wrong way about this guys. The deletion of text in revision mode should not be thought of as deteletion from the piecetable, but merely as a formatting change. Text deleted in revision mode is not deleted, merely marked with an attribute 'so and so thought this should be deleted'. Only when the document is back in the normal mode and the user is accepting a delete-type revision the marker 'this should be deleted' gets translated into a real delete operation. This is simple and requires just adding the extra couple of attributes to indicated changes made in revision mode. We then jsut need to remap the deletion operations when you enter revisions mode to simple formatting changes; no need to modify the PT (and the great thing is that the Undo will automatically work, since it already handles formatting changes). Then we need to add decent user interface + some trickery to the layout classes to hide/unhide the text marked as revised depending on what the user wants to see, and that should be pretty much it. Tomas
