[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: undo weirdness with insert-file-contents

From: Bill Wohler
Subject: Re: undo weirdness with insert-file-contents
Date: Sun, 02 Mar 2008 14:18:31 -0800

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]