Re: undo weirdness with insert-file-contents

[Stefan Monnier <monnier@iro.umontreal.ca>]

> the empty_undo_list check at all.  BTW, what is the semantics of
> `insert-file-contents' with VISIT nil and REPLACE non-nil?

It seems obvious to me that it's similar to "delete + insert".
So I guess I don't understand the question quite right.  I use this kind
of call to insert-file-contents in smerge-resolve, if you want to see
an example.

>> Also if the file is empty, is this going to mark the buffer as modified
>> even though nothing was changed?

> I'm afraid I don't understand the question - do you mean the case where
> inserted equals zero?

Yes.

> I don't handle that.

What does that mean?  Are you going to mark the buffer as modified?

> + 	/* Else if the present insertion is the very first change of the
> + 	   current buffer, undo information is recorded, and we are
> + 	   neither visiting a file nor replacing buffer contents, make
> + 	   sure we record the insertion as a first change in the
> + 	   undo-list.  This is needed in order to avoid that undoing the
> + 	   insertion leaves the buffer's modified state set.  */
> + 	{
> + 	  current_buffer->undo_list = Qnil;
> + 	  record_first_change ();
> + 	}

Normally record_first_change is called "automatically" elsewhere.
So why is it needed here?

The handling of the undo-list and modified-p status in
insert-file-contents is a real mess.  It'd be good to take a step back
and think about how it *should* work.  E.g. I don't think
insert-file-contents should mess with modified-p: it should behave just
like a normal `insert' in this respect.


        Stefan