From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: New undo element (fun . args) Date: Sat, 05 Feb 2005 12:39:26 -0500 Message-ID: References: <87fz0jyn19.fsf-monnier+emacs@gnu.org> <87mzunvyki.fsf-monnier+emacs@gnu.org> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1107625596 8158 80.91.229.2 (5 Feb 2005 17:46:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 5 Feb 2005 17:46:36 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 05 18:46:35 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CxU0s-0007oO-1S for ged-emacs-devel@m.gmane.org; Sat, 05 Feb 2005 18:46:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CxUEd-0006Vp-JH for ged-emacs-devel@m.gmane.org; Sat, 05 Feb 2005 13:00:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CxUEB-0006UB-8s for emacs-devel@gnu.org; Sat, 05 Feb 2005 13:00:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CxUE7-0006Ru-Oi for emacs-devel@gnu.org; Sat, 05 Feb 2005 13:00:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CxUE7-0006QM-DK for emacs-devel@gnu.org; Sat, 05 Feb 2005 13:00:11 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CxTx6-0007tu-LJ for emacs-devel@gnu.org; Sat, 05 Feb 2005 12:42:36 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1CxTu2-0001gm-IJ; Sat, 05 Feb 2005 12:39:26 -0500 Original-To: storm@cua.dk (Kim F. Storm) In-reply-to: (storm@cua.dk) 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:32907 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32907 I may have misunderstood something too, but IIUC, this checks to see if the buffer-undo-list has not been modified since the last undo -- by comparing the current head of buffer-undo-list with the the head of the buffer-undo-list at the end of the last undo as it was recorded in undo-equiv-table. That is right. So whether that last undo command added anything to buffer-undo-list or not doesn't seem relevant, as the head of the buffer undo list should be in the undo-equiv-table in both cases, If an undo command does not generate any undo entries, it will have to put into undo-equiv-table a head-of-list that was produced by some other command, which may not have been an undo command. That is certainly not supposed to happen. Whether it actually leads to incorrect results, I don't know. So this would be a problem only in the case where (apply ...) is the only action between two undo boundaries. To work around this, it seems to be sufficient to add just one element at the end of Fprimitive_undo in case the undo list hasn't changed at all. Yes, I think so. BTW, I suppose that the apply undo function is not allowed to change current buffer. Yes it can. That is why it can specify a DELTA.