Re: undo weirdness with insert-file-contents

[martin rudalics <rudalics@gmx.at>]

 >>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.