Re: undo weirdness with insert-file-contents

[Bill Wohler]

Stefan Monnier <address@hidden> wrote:

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

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.

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.

-- 
Bill Wohler <address@hidden>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD