From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: New undo element (fun . args) Date: Fri, 04 Feb 2005 16:40:57 +0100 Message-ID: References: <87fz0jyn19.fsf-monnier+emacs@gnu.org> <87mzunvyki.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1107532608 32021 80.91.229.2 (4 Feb 2005 15:56:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 4 Feb 2005 15:56:48 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 04 16:56:47 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Cx5ow-0004EP-LG for ged-emacs-devel@m.gmane.org; Fri, 04 Feb 2005 16:56:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cx62U-00031h-Bb for ged-emacs-devel@m.gmane.org; Fri, 04 Feb 2005 11:10:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cx5sd-0000P2-OG for emacs-devel@gnu.org; Fri, 04 Feb 2005 11:00:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cx5sN-0000HS-Mz for emacs-devel@gnu.org; Fri, 04 Feb 2005 11:00:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cx5sM-0000GU-Qg for emacs-devel@gnu.org; Fri, 04 Feb 2005 11:00:06 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1Cx5Zr-00078u-04 for emacs-devel@gnu.org; Fri, 04 Feb 2005 10:40:59 -0500 Original-Received: (qmail 81188 invoked from network); 4 Feb 2005 15:40:57 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 4 Feb 2005 15:40:57 -0000 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Thu, 03 Feb 2005 14:13:28 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) 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:32875 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32875 Richard Stallman writes: > /* Make sure this produces at least one undo entry, > so the test in `undo' for continuing an undo series > will work right. */ > if (EQ (oldlist, current_buffer->undo_list)) > current_buffer->undo_list > = Fcons (list3 (Qapply, Qcdr, nil), current_buffer->undo_list); > > I don't understand why this is necessary. The primitive-undo > continues to the next undo boundary, so why is it important what is > recorded "between undo boundaries" ? > > I think it is necessary for this code to work: > > ;; If something (a timer or filter?) changed the buffer > ;; since the previous command, don't continue the undo seq. > (let ((list buffer-undo-list)) > (while (eq (car list) nil) > (setq list (cdr list))) > ;; If the last undo record made was made by undo > ;; it shows nothing else happened in between. > (gethash list undo-equiv-table)))) > > If undoing does not generate any undo entries, there will be nothing > for this hash mark to ride on. However, I may have misunderstood > something. 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. 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, and gethash should succeed in both cases. I will experiment with removing the (apply cdr nil) element and see if it breaks things. BTW, I suppose that the apply undo function is not allowed to change current buffer. And maybe we should signal an error in primitive-undo if it does. > > It works > to some extent, but as soon as undo hits one of the entries I added to > the undo list, it gets stuck -- and the pending undo list seems to > be stuck at that specific (apply cdr ...) entry. > > Could you debug precisely what is happening when it is "stuck" as you > say? I'm trying :-) > In what way does the undo process fail to work? Where is the bug? I'm not sure it is a bug in the undo machinery or the way I try to use it in cua, or a combination... PS: If it turns out that my understanding is wrong, my concern with adding (apply cdr nil) is when the (apply ...) element is only one among several undo elements between two undo boundaries--as long as just one of those elements generate an undo element in buffer-undo-list it should be sufficient to fulfill that requirement. 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. -- Kim F. Storm http://www.cua.dk