From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry OReilly Newsgroups: gmane.emacs.bugs Subject: bug#16377: Undo Tree regression: (error "Unrecognized entry in undo list undo-tree-canary") Date: Wed, 22 Jan 2014 10:26:05 -0500 Message-ID: References: <20140122141701.GA6728@c3po> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113639104ed25904f090bea0 X-Trace: ger.gmane.org 1390404433 14344 80.91.229.3 (22 Jan 2014 15:27:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jan 2014 15:27:13 +0000 (UTC) To: Toby Cubitt , 16377-done@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 22 16:27:18 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W5zi1-0006rJ-W4 for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 Jan 2014 16:27:18 +0100 Original-Received: from localhost ([::1]:35763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5zi1-0002ra-Hh for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 Jan 2014 10:27:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5zht-0002pT-Hs for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 10:27:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5zho-0004Fj-0N for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 10:27:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5zhn-0004FY-Pu for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 10:27:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W5zhn-0006ns-Gx for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 10:27:03 -0500 Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Jan 2014 15:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 16377 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Mail-Followup-To: 16377@debbugs.gnu.org, gundaetiapo@gmail.com, gundaetiapo@gmail.com Original-Received: via spool by 16377-done@debbugs.gnu.org id=D16377.139040437226080 (code D ref 16377); Wed, 22 Jan 2014 15:27:02 +0000 Original-Received: (at 16377-done) by debbugs.gnu.org; 22 Jan 2014 15:26:12 +0000 Original-Received: from localhost ([127.0.0.1]:60779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W5zgx-0006mY-10 for submit@debbugs.gnu.org; Wed, 22 Jan 2014 10:26:11 -0500 Original-Received: from mail-oa0-f44.google.com ([209.85.219.44]:60563) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W5zgs-0006mO-OI for 16377-done@debbugs.gnu.org; Wed, 22 Jan 2014 10:26:07 -0500 Original-Received: by mail-oa0-f44.google.com with SMTP id g12so599457oah.17 for <16377-done@debbugs.gnu.org>; Wed, 22 Jan 2014 07:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Gl68iFLRR/o8H73uI0/nZm3P1xcbZa6QaJyNEdcWRn0=; b=xsDAhIS2+mmtL+FzSWcJi/dKnRfMsAjzqNVza4kA2fsBMa9fYCOfTNB0ZzCAOgmFUM E+QKet3eiDCve3Ru/S5p89joiLRD1VQagQGNATDUyiOLEXwg95LEMBT49jTfO4iQLGpS 92A8zLpU5rHTA6vEgOKD51LQr9S9AFcK8R6fopbGDDongmM3fJIPy5gpKyaqu2cuYG1Z np+hqmIuR9bziq0TSi53qA+Xir/+TUpRNixP1Pib0tSEsH7OnpyAlb8p7E0hClEpvYu9 Bn08gdfV1MW1QjMa4tcSOFk0VFuARWtrn+LinWlyzBOcJOoTBz5JTL0sdaP4t29RFen2 KACw== X-Received: by 10.60.228.135 with SMTP id si7mr1806146oec.4.1390404365631; Wed, 22 Jan 2014 07:26:05 -0800 (PST) Original-Received: by 10.76.21.84 with HTTP; Wed, 22 Jan 2014 07:26:05 -0800 (PST) In-Reply-To: <20140122141701.GA6728@c3po> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:83883 Archived-At: --001a113639104ed25904f090bea0 Content-Type: text/plain; charset=ISO-8859-1 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'll close the Emacs bug since we're fairly sure at this point it's an undo-tree bug. --001a113639104ed25904f090bea0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 22, 2014 at 9:17 AM, Toby Cubitt <toby-dat= ed-1391609828.ede38b@dr-qubit.org> wrote:
On Tue, Jan 21, 2014 at 0= 7:05:38PM -0500, Barry OReilly wrote:
> > The "Unrecognised entry" error suggests the undo-tree-c= anary 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 eve= r be
in buffer-undo-tree. (And maybe it isn't, I'm just guessing from th= e
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 canar= y 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-mod= e
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:

=A0 (setf (undo-tree= -node-undo current)
=A0=A0=A0=A0=A0=A0=A0 (undo-list-pop-changeset '= discard-pos))

In undo-list-pop-changeset:

=A0 (if (eq (car bu= ffer-undo-list) 'undo-tree-canary)
=A0=A0=A0=A0=A0 (push nil buffer-undo-list)
=A0=A0=A0 [...])

The = push call returns (nil 'undo-tree-canary). This is how it gets
into = the buffer-undo-tree in my reproduction.

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

--001a113639104ed25904f090bea0--