Andre Poenitz wrote: > On Tue, Nov 30, 2004 at 05:37:34PM +0100, Alfredo Braunstein wrote: >> >> There are some things of that patch I don't understand. >> >> >> >> In textUndoOrRedo 1) what does the bv.cursor has to do with anything? >> > >> > It should be needed to e.g. give the target for the Undo struct that >> > will be pushed on the redo stack. >> >> [I don't understand what you mean by 'target'] > > The target is he position where the cursor will be put after 'undo'. > >> So we store a cursor position with the undo information, in addition to >> undo.cell which points to the inset of the paragraph range. And for some >> reason, we need this position to be *inside* the undo range. (or at >> least, in the same inset of the undo paragraph range). Why? > > Because I thought that changes always happen at or near cursor position.
Agreed (in almost all cases). Note that we may want to *force* the cursor to be near the change, for visual reasons; but extending the change up to near the cursor doesn't make much sense to me. >> This is particularly broken in the current undo/redo scheme: suppose you >> do a minor change inside some small inset, then go with the cursor to the >> end of the document and do an 'undo': then the full document would be >> recorded as 'redo' information? This would be the result of the >> "intersection" above. > > A right. That's bad... So maybe we need 'cursor warp' undo items that > only record cursor positioning. > > Or maybe the requirement that the cursor position be in the undo range > is not needed at all? I can't really remember why I needed that. > > So do you think an iterator pointing to a cell + two par offsets + an > independent iterator for the cursor would be ok as undo struct? I think so. I'll have a look. Regards, Alfredo
