From: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: New undo element (fun . args)
Date: Sat, 05 Feb 2005 12:39:26 -0500 [thread overview]
Message-ID: <E1CxTu2-0001gm-IJ@fencepost.gnu.org> (raw)
In-Reply-To: <m3sm4cuyd2.fsf@kfs-l.imdomain.dk> (storm@cua.dk)
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.
next prev parent reply other threads:[~2005-02-05 17:39 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
2005-02-05 17:39 ` Richard Stallman [this message]
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=E1CxTu2-0001gm-IJ@fencepost.gnu.org \
--to=rms@gnu.org \
--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).