Re: undo weirdness with insert-file-contents

[Stefan Monnier]

> 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