Re: undo weirdness with insert-file-contents

[martin rudalics]

>>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.
>
> I agree. The semantics of insert-file-contents seems to be identical to
> insert--only the text comes from a file rather than an argument.

`insert-file-contents' is used to set up the buffer when visiting a
file.  In that case you hardly want the buffer appear modified after
reading in the file or `point' appear at eob.  Also the whole REPLACE
handling is hardly comparable to what `insert' does (although it's
similar to active region handling with `delete-selection-mode').

> I'd therefore be against Martin's suggestion of inserting an undo
> boundary since that should be the caller's responsibility (typically,
> the command loop). Consider the following:
>
>     (defun bw-foo ()
>       (insert "abc")
>       (insert "def"))
>
>     (defun bw-bar ()
>       (insert-file-contents "/etc/motd")
>       (insert-file-contents "/etc/motd"))
>
> A single undo in either case will remove both insertions and reset
> buffer-modified-p to nil if that's what it was beforehand.

I have no opinion here.  But if you insert the second region _before_
the first region you need two undos anway.  Making the behavior depend
on some imaginary left-to-right order is hardly reasonable.  But I agree
that my undo boundary is purely artifical here I should remove it after
it has served its purpose.  A cleaner solution would be to use an extra
variable, say record_insert_no_combine, bind it to Qt in
`insert-file-contents', and have record_insert not combine two adjacent
insertions when this variable is non-nil.  Afterwards I can always
combine the insertions if people want it.

> There is, regrettably, a large difference between these two. Point is
> left where insert-file-contents was run rather than at the end of the
> inserted string as is the case with insert. Maybe we should consider
> fixing this at this time as well. Maybe this is the way it used to work,
> or maybe this is the way people expect it to work: I took a quick look
> at the MH-E code and many invocations of insert-file-contents are
> immediately followed by (goto-char (point-min)) before the inserted file
> is processed.

As explained above: The primary use of `insert-file-contents' is to set
up file-visiting buffers not to modify them.