Re: 4 minor suggestions for files.el

["Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>]

>     > I think that the correct way for check-in and update to interact with
>     > M-x undo is to transpose the old undo list somehow to the buffer as it
>     > has been updated.
> 
>     That's what undo-in-region does.
> 
> undo-in-region does a special case of this.  It does not handle the
> generality that would be needed for this, and I think that would require
> new methods.

Sure, it's not quite the same, but I use it to get the desired result.

>     > Likewise, if I edit the buffer and then do a CVS update, I should
>     > then be able to undo the edit I made, but not the changes made by
>     > the CVS update.
> 
>     Why not ?
> 
> When you do a CVS update, you don't know what changes are getting
> merged in.  You often don't see them; they are in parts of the file
> where you have not been working.
> 
> If a single undo operation would undo all of them, you would lose
> them and not know what you are losing.  That is risky and not the
> right interface.
> 
> In order for undo in Emacs to operate in a predictable and reliable
> way, it should undo the changes that you made with your editing.  If
> you want to undo the changes that came from CVS, that should be a
> separate command, designed to coordinate with CVS.  What I have in
> mind is a command to take out the changes that were made between a
> certain pair of versions.

CVS generally doesn't know: the local file generally has local
modifications (otherwise, there's generally no interesting undo log
to worry about) so the merge done by `cvs update' is not the same
as the change recorded in the repository.

Also, most of the time that I use such an undo, it's only to temporarily
take a look at a previous state of the buffer: I virtually never
want to save the file with the change undone.  The only exception
is when I want to undo (in the repository) a change I installed
recently, but I rarely if ever use Emacs undo for it (I use `cvs diff'
and reverse-apply the patch, instead).

I.e. in my experience, undoing the revert (rather than only undoing changes
done before the revert) never hurts and is sometimes useful.  I see
cases where your refinement (i.e. adjusting the "before revert" undo
log so it applies to the "after revert" buffer) can be marginally better,
but I doubt it's worth the effort, especially since it prevents the
user from undoing the revert itself which can also be something she wants
to do.


	Stefan