unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: storm@cua.dk (Kim F. Storm)
Cc: emacs-devel@gnu.org
Subject: Re: New undo element (fun . args)
Date: Fri, 04 Feb 2005 16:40:57 +0100	[thread overview]
Message-ID: <m3sm4cuyd2.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <E1CwmPw-00035j-MS@fencepost.gnu.org> (Richard Stallman's message of "Thu, 03 Feb 2005 14:13:28 -0500")

Richard Stallman <rms@gnu.org> 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 <storm@cua.dk> http://www.cua.dk

  reply	other threads:[~2005-02-04 15:40 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-30  0:47 New undo element (fun . args) Kim F. Storm
2005-01-30  1:24 ` Miles Bader
2005-01-30 15:07   ` Stefan Monnier
2005-01-30 17:22     ` Kim F. Storm
2005-01-30 18:11     ` Kim F. Storm
2005-01-31 12:01     ` Richard Stallman
2005-01-31 13:02       ` Kim F. Storm
2005-01-31 22:53         ` Kim F. Storm
2005-02-02  7:28           ` Richard Stallman
2005-02-02  7:28         ` Richard Stallman
2005-02-02 14:35           ` Stefan Monnier
2005-02-02 15:41             ` Kim F. Storm
2005-02-03 19:13               ` Richard Stallman
2005-02-04 15:40                 ` Kim F. Storm [this message]
2005-02-05 17:39                   ` Richard Stallman
2005-02-07  8:23                     ` Kim F. Storm
2005-02-07 20:51                       ` Richard Stallman
2005-02-09 21:50                         ` Kim F. Storm
2005-02-07 11:51                   ` Kim F. Storm
2005-02-07 12:25                     ` David Kastrup
2005-02-07 14:14                       ` Stefan Monnier
2005-02-08 11:47                       ` Richard Stallman
2005-02-08 11:46                     ` Richard Stallman
2005-02-08 12:53                       ` Kim F. Storm
2005-02-03 19:13             ` Richard Stallman
2005-01-31  0:19 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3sm4cuyd2.fsf@kfs-l.imdomain.dk \
    --to=storm@cua.dk \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).