savannah: undo does not reset "modified" status

[ossi]

Original: ​http://savannah.gnu.org/bugs/?13737

Submitted by:	Oswald Buddenhagen <ossi>	Submitted on:	Mon 11 Jul 2005 07:56:26 PM UTC
Category:	Editor	Severity:	3 - Normal
Status:	None	Privacy:	Public
Assigned to:	None	Open/Closed:	Open
Release:	current (CVS or snapshot)	Operating System:	All

Original submission:

i often accidentally do minor modifications (mostly partial escape 
sequences) which i undo of course. anyway, afterwards i still don't 
know if this was the only modification.

some considerations for the implementation:
- movements don't change the modified status, so you can't just 
check whether the undo stack is at the last file save point
- undo of changes past the last file save point must re-assert the 
modified status
- at file save points, it would make sense to stop undoing if it 
results from keyboard auto-reapeat (which can be assumed if the 
same sequence arrives (lets say) fife times within one second). 
undo will be resumed when the key is re-asserted after a pause. 

[styx]

branch: 26_undo_reset_modified
changeset: 79748bad3d00cfa2eb164711a899aeda4666d6e6

Check pls, is 'edit->stack_wrapped = TRUE;' placed well and have an additional look for this place:
/*If a single key produced enough pushes to wrap all the way round then ...
It looks like stack_wrapped = TRUE should be placed there but practice says 'no'...

[iNode]

Open file, write test (change flag is up), press F2(chabge flag is down).
Press C-u once (change flag is up), again, again, again (change flag is down).
Is it correct behavoiur?

[ossi]

Replying to iNode:

Is it correct behavoiur?

doesn't sound so. imagine the undo history as a stream of changes. each time when a file is loaded or saved (i.e., when the editor buffer is synchronized with the disk contents), the pointer for the unmodified state is set. now, if the "action" pointer is moved through the history (via undo or (the non-existing) redo), you look whether there are any modifying commands between the action pointer and the unmodified state pointer - if so, you raise the modified flag. of course, the checking should happen incrementally, possibly by inc-/decrementing a counter each time a modifying command is un-/redone.

[angel_il]

Is it correct behavoiur?

i think it's really correct behavoiur. after your file saved you add new changes.

[iNode]

Replying to angel_il:

Is it correct behavoiur?

i think it's really correct behavoiur. after your file saved you add new changes.

May be I should use special markup for incorrect behavoiur: change flag is down not in history position where we save file.

[iNode]

Use case: user open file, edit and save. He understand bug in changes (invalid state) and undo to open file position. And quit without save or confirmations because change flag is down, but file on disc in invalid state.