Re: bug in replace-string: widget loses characters

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Tue, 09 Oct 2012 08:24:25 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Oct 9,  3:34pm, Peter Stephenson wrote:
> }
> } The one side effect is that $UNDO_CHANGE_NO is different each time
> it's } read.  I could fix that if anyone cared, but if it helped you
> could sort } of look on it as a feature: you are guaranteed that all
> recorded change } points are unique and monotonically increasing
> whether or not the line } itself was changed.
> 
> I think this is OK, but I suppose there might be a case where one
> wanted to be able to detect whether any changes had occurred between
> state X and state Y, e.g. previously
> 
> 	local current_undo=$UNDO_CHANGE_NO
> 	# ... some stuff potentially happens ...
> 	if (( current_undo == UNDO_CHANGE_NO ))
> 	then
> 	  # nothing happened?
> 	fi
> 
> Is there another way to detect this?  It's probably not a common thing
> to care about so perhaps not worth a lot of effort.

Well, with the current set-up you'd be guaranteed that the second call
would be an increment of 1 from the first.  You need to be careful how
many times you call UNDO_CHANGE_NO, though, so it's not very robust.

If it seems a preferable way of doing it, it's straightforward to add a
flag saying who last incremented the number, so it only gets incremented
the first time.  The change numbers for the edits are hidden, so that
ought to do the trick.

-- 
Peter Stephenson <p.stephenson@xxxxxxxxxxx>       Consultant, Software
Tel: +44 (0)1223 434724              Samsung Cambridge Solution Centre
St John's House, St John's Innovation Park,
Cowley Road, Cambridge, CB4 0ZT, UK