all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Toby Cubitt <toby-dated-1391619923.a57a98@dr-qubit.org>
To: 16377@debbugs.gnu.org, gundaetiapo@gmail.com
Subject: bug#16377: Undo Tree regression: (error "Unrecognized entry in undo list undo-tree-canary")
Date: Wed, 22 Jan 2014 17:05:18 +0000	[thread overview]
Message-ID: <20140122170518.GA19716@c3po> (raw)
In-Reply-To: <CAFM41H3Z2Rzt3V-WLc98++J4Av48Wrm9r9HkqKgjn4ufxWTJAw@mail.gmail.com>

On Wed, Jan 22, 2014 at 10:26:05AM -0500, Barry OReilly wrote:
> On Wed, Jan 22, 2014 at 9:17 AM, Toby Cubitt <
> toby-dated-1391609828.ede38b@dr-qubit.org> wrote:
> 
> > On Tue, Jan 21, 2014 at 07:05:38PM -0500, Barry OReilly wrote:
> > > > The "Unrecognised entry" error suggests the undo-tree-canary symbol
> > > > has somehow ended up in a `buffer-undo-tree' entry.
> > >
> > > You mean "buffer-undo-list" not "buffer-undo-tree" right?
> >
> > No, I mean `buffer-undo-tree'. The canary should never end up there. In
> > undo-tree-mode, primitive-undo only ever gets called on an entry copied
> > from buffer-undo-tree. Hence my statement, above.
> >
> > > I checked Emacs 24.3 and as I suspected it's quite easy to make
> > > undo-tree-canary appear in the buffer-undo-list.
> >
> > It's *supposed* to be in buffer-undo-list. It's not supposed to ever be
> > in buffer-undo-tree. (And maybe it isn't, I'm just guessing from the
> > error message here. I haven't had time to investigate yet.)
> >
> > > What changed is the error checking in core Emacs. If you expected that
> > > undo-tree-canary would never be there between commands, that has not
> > > been so for some time.
> >
> > I didn't expect that.
> >
> > > Could you tell me more about the purpose of undo-tree-canary?
> >
> > It lets undo-tree-mode detect when Emacs has discarded undo history from
> > buffer-undo-list "behind undo-tree-mode's back". If the canary has
> > vanished when undo-tree-mode looks at buffer-undo-list, Emacs must have
> > purged some undo history.
> >
> > The new error checking in primitive-undo shouldn't affect undo-tree-mode
> > in any way. I still strongly suspect this is a bug in the very delicate
> > and relatively untested undo-in-region code, and the change to
> > primitive-undo is a red herring.
> >
> >
> In undo-tree-redo-1:
> 
>   (setf (undo-tree-node-undo current)
>         (undo-list-pop-changeset 'discard-pos))
> 
> In undo-list-pop-changeset:
> 
>   (if (eq (car buffer-undo-list) 'undo-tree-canary)
>       (push nil buffer-undo-list)
>     [...])
> 
> The push call returns (nil 'undo-tree-canary). This is how it gets
> into the buffer-undo-tree in my reproduction.

I think this is still a symptom, not the ultimate cause of the bug
(though I should probably guard against this better). `undo-tree-redo-1'
has previously called `primitive-undo', so you would expect
`buffer-undo-list' to contain at least one undo changeset (the one added
by `primitive-undo') when `undo-list-pop-changeset' is called.

Are there circumstances in which `primitive-undo' doesn't add to
`buffer-undo-list'?

Anyway, I need to step through the code and figure out what's going
on. Which I'll do as soon as I have a block of free time to set aside for
elisp debugging.

> I'll close the Emacs bug since we're fairly sure at this point it's an
> undo-tree bug.

Yup, fine by me. I think what's happened is that the new error checking
in `primitive-undo' simply caught this undo-tree bug (so it's doing its
job!)

Toby
-- 
Dr T. S. Cubitt
Royal Society University Research Fellow
and Fellow of Churchill College, Cambridge
Centre for Quantum Information
DAMTP, University of Cambridge

email: tsc25@cantab.net
web:   www.dr-qubit.org





  reply	other threads:[~2014-01-22 17:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-07  0:32 bug#16377: Undo Tree regression: (error "Unrecognized entry in undo list undo-tree-canary") Barry OReilly
2014-01-07  4:14 ` Toby Cubitt
2014-01-22  3:23   ` Barry OReilly
2014-01-22 17:08     ` bug#16523: " Toby Cubitt
2014-01-08  3:37 ` bug#16377: " Toby Cubitt
2014-01-22  0:05   ` Barry OReilly
     [not found]     ` <20140122141701.GA6728@c3po>
2014-01-22 15:26       ` Barry OReilly
2014-01-22 17:05         ` Toby Cubitt [this message]
2014-01-22 18:56           ` Stefan Monnier
2014-01-22 21:30             ` Toby Cubitt
2017-07-06  0:33 ` Keith David Bershatsky
2017-07-06  5:01 ` Keith David Bershatsky
2017-07-06  5:35   ` Stefan Monnier
2017-07-06  6:25 ` Keith David Bershatsky
2017-07-06  9:02   ` Toby Cubitt
2017-07-06  9:47     ` Toby Cubitt

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

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

  git send-email \
    --in-reply-to=20140122170518.GA19716@c3po \
    --to=toby-dated-1391619923.a57a98@dr-qubit.org \
    --cc=16377@debbugs.gnu.org \
    --cc=gundaetiapo@gmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.