From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: undo in loaddefs.el buffer Date: Mon, 3 Jan 2005 21:07:11 -0600 (CST) Message-ID: <200501040307.j0437Bs12647@raven.dms.auburn.edu> References: <200412211414.iBLEEZ903426@raven.dms.auburn.edu> <200412211541.iBLFfBc03861@raven.dms.auburn.edu> <87llbonyup.fsf@jurta.org> <200412260206.iBQ26wG17970@raven.dms.auburn.edu> <41CEE3B8.9090600@swipnet.se> <200412270231.iBR2VDE19709@raven.dms.auburn.edu> <41CFE247.8090409@swipnet.se> <200412280503.iBS53deD002564@manatee.dms.auburn.edu> <200412290207.iBT27Gk0006913@manatee.dms.auburn.edu> <200412300114.iBU1EY001351@moose.dms.auburn.edu> <200412310154.iBV1s5w05229@raven.dms.auburn.edu> <200412311504.iBVF4QO05860@raven.dms.auburn.edu> <200501021602.j02G23x08404@raven.dms.auburn.edu> Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Clf2p-0003Dy-00 for ; Tue, 04 Jan 2005 04:07:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClfE0-0001II-Is for ged-emacs-devel@m.gmane.org; Mon, 03 Jan 2005 22:19:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1ClfDt-0001I4-VJ for emacs-devel@gnu.org; Mon, 03 Jan 2005 22:19:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1ClfDt-0001Hf-2m for emacs-devel@gnu.org; Mon, 03 Jan 2005 22:19:05 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClfDs-0001Hc-Ul for emacs-devel@gnu.org; Mon, 03 Jan 2005 22:19:05 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Clf2Y-0007KW-3s; Mon, 03 Jan 2005 22:07:22 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j0437L0P017695; Mon, 3 Jan 2005 21:07:21 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j0437Bs12647; Mon, 3 Jan 2005 21:07:11 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Sun, 02 Jan 2005 19:58:50 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:31784 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31784 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