emacs-devel
[Top][All Lists]
Advanced

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

Re: undo in loaddefs.el buffer


From: Luc Teirlinck
Subject: Re: undo in loaddefs.el buffer
Date: Mon, 3 Jan 2005 21:07:11 -0600 (CST)

Richard Stallman wrote:

       As I already pointed out, the only non-obvious requirement is that one
       way or the other they have to take care of undo correctly.

   Yes.  If you could make sure that this issue is clearly explained
   in comments in the code, that would be a good thing.

There is one obvious requirement, but two issues.  The first issue is
the general question of what it means to timers and idle timers in
general, whether they write into user buffers or into non-user buffers.
The second question is the way more specialized question of what it
means to autoreverting non-file buffers.  Actually, there might be the
third question of whether the general problem is really limited to
timers or applies in exactly the same way to asynchronous processes
that might write their output repeatedly into a buffer.

Before going into the autorevert specific problem, let me state what I
believe what our conclusion to the _general_ problem was.

I believe it was that the person writing a timer function that writes
at regular time intervals into a buffer needs to know that there is
the danger of accumulating one huge single undo entry and running out
of memory.  Something needs to be done about it, which could be
disabling undo, clearing out the undo info or putting in two undo
boundaries.  These points have to be made clear in `(elisp)Timers'
which currently says:

       It is usually a bad idea for timer functions to alter buffer
    contents.  When they do, they usually should call `undo-boundary' both
    before and after changing the buffer, to separate the timer's changes
    from user commands' changes.

I believe that there still are problems with this.

Although this was not the point of our discussion, it indeed would
usually seem better to put in two undo boundaries even if the timer
only runs once (in which case there are no memory problems), for the
reason given above.  But running out of memory is not mentioned and
the memory problem occurs _regardless_ of whether the buffer is a buffer
the user might want to write into.  (Several buffers in which the user
usually does not write have undo enabled, say Dired, Buffer Menu...)

I would replace the above quote with:

      If a timer function alters buffer contents, it usually should call
    `undo-boundary' both before and after changing the buffer, to separate
    the timer's changes from user commands' changes.  If the timer runs
    repeatedly, this also avoids accumulating one huge undo entry, which
    can cause memory problems.

The line " It is usually a bad idea for timer functions to alter
buffer contents.", could be left in, but it really serves no purpose
whatsoever.  Nobody is going to be tempted to make a timer alter
buffer contents without having good reasons to do so.

In as far as the autorevert issue is concerned, there is no problem
with autoreverting file buffers, or with the two currently
autoreverted non-file buffers.  Auto Revert Tail is an isolated case
and has been taken care of.

Which leaves autoreverting additional non-file buffers.  There I
understood that the revert-buffer-function was supposed to clear out
all undo info and that if it did not, the revert-buffer-function
should be changed to do that.  Did I understand this correctly?  If
yes, should that not actually be pointed out in the Elisp manual and
docstring documentation of `revert-buffer-function'?

I gave an overview of the various difficulties in autoreverting
non-file buffers in emacs-xtra.  (There is a link to this in the
docstring of `global-auto-revert-non-file-buffers'.)  I could add to
that list the need to check whether the revert-buffer-function really
sets the undo info to nil and to change that function if it does not.

Sincerely,

Luc.


I 




reply via email to

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