From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Toby Cubitt Newsgroups: gmane.emacs.bugs Subject: bug#16377: Undo Tree regression: (error "Unrecognized entry in undo list undo-tree-canary") Date: Thu, 6 Jul 2017 10:02:56 +0100 Message-ID: <20170706090256.GA20017@marvin.cs.ucl.ac.uk> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1499354364 25168 195.159.176.226 (6 Jul 2017 15:19:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Jul 2017 15:19:24 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: 16377@debbugs.gnu.org, Barry OReilly , Stefan Monnier To: Keith David Bershatsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 06 17:19:17 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dT8Yg-0006AX-V7 for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Jul 2017 17:19:11 +0200 Original-Received: from localhost ([::1]:51947 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dT8Ym-0003gZ-CF for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Jul 2017 11:19:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dT8Yb-0003eA-6Y for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2017 11:19:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dT8YY-0002nJ-1e for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2017 11:19:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52622) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dT8YX-0002mz-Td for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2017 11:19:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dT8YX-0006TE-Oz for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2017 11:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Toby Cubitt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Jul 2017 15:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16377 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16377-submit@debbugs.gnu.org id=B16377.149935431424830 (code B ref 16377); Thu, 06 Jul 2017 15:19:01 +0000 Original-Received: (at 16377) by debbugs.gnu.org; 6 Jul 2017 15:18:34 +0000 Original-Received: from localhost ([127.0.0.1]:55299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dT8Y5-0006SQ-Pp for submit@debbugs.gnu.org; Thu, 06 Jul 2017 11:18:34 -0400 Original-Received: from starfish.geekisp.com ([216.168.135.166]:17032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dT2gj-0004De-6a for 16377@debbugs.gnu.org; Thu, 06 Jul 2017 05:03:05 -0400 Original-Received: (qmail 32699 invoked by uid 1003); 6 Jul 2017 09:02:58 -0000 Original-Received: from unknown (HELO marvin.localdomain) (toby@dr-qubit.org@128.16.15.253) by mail.geekisp.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Jul 2017 09:02:58 -0000 Original-Received: by marvin.localdomain (Postfix, from userid 1000) id B30502C58CF5; Thu, 6 Jul 2017 10:02:56 +0100 (BST) Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.dr-qubit.org/gpg-toby-pub.asc X-Mailman-Approved-At: Thu, 06 Jul 2017 11:18:32 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:134265 Archived-At: On Wed, Jul 05, 2017 at 11:25:10PM -0700, Keith David Bershatsky wrote: > The existence and discussion surrounding `undo-tree.el` predates my > usage of that library, but from what I can tell, at some point in the > past `primitive-undo' was "improved" to start checking for errors and > this resulted in bug #16377. No, the new error checking just helpfully revealed an existing bug in undo-tree's undo-in-region support (which frankly has always been flaky, as it's extraordinarily difficult to reliably reproduce undo bugs). There's even an `undo-tree-enable-undo-in-region' toggle to disable undo-in-region support, for exactly this reason. Probably I should make it default to "off" for now. I'm way behind on dealing with undo-tree bug reports whilst busy with "real life". #16377 is a very helpful bug report, which I can now reproduce much more reliably with current Emacs version than I could when it was originally reported. I hope to have time for a mammoth undo-tree maintenance session later this summer. If that works out, I'll look into it then. > From an untrained layman's way of thinking, I am "guessing" that if > undo-tree worked fine before `primitive-undo` was modified to throw an > error, then perhaps it is not "a problem" with undo-tree except to the > extent that undo-tree may need to "evolve" to play nice with the > current version of `primitive-undo`. The undo-tree-canary symbol should never end up in the list passed by undo-tree to `primitive-undo', so it shouldn't matter whether it throws an error. `primitive-undo' throwing an error on garbage, as in current Emacs, makes complete sense from my perspective. > Based on that "optional evolution theory", I created the workaround to > just throw an informative message instead of an error. However, I do > not know if that approach could lead to problems. I deliberately didn't touch `primitive-undo' in undo-tree. It was a c primitive when I wrote undo-tree, and overriding primitives is not a good idea. Even now, I wouldn't recommend overriding it without rewriting undo-tree so it completely rips out and replaces the Emacs undo system. (If that's even possible -- it didn't used to be because too much was done in c.) As currently implemented, undo-tree sits on top of the standard Emacs undo system and overrides as little as possible. I certainly wouldn't disable the error reporting, since that just masks the bug, it doesn't fix it. > I've spent quite a bit of time studying certain sections of the > undo-tree.el library, but there are sections of the code that are > still "Greek to me". My understanding of the `undo-tree-canary` > symbol inside the `buffer-undo-list` is that it is a way for undo-tree > to check if it has interacted with the `buffer-undo-list`. The *only* purpose of the undo-tree-canary is to detect when Emacs has discarded undo history from buffer-undo-list before undo-tree got to look at it. In that situation, the entire contents of buffer-undo-tree gets discarded (because it only contains undo history that's being discarded), and gets rebuilt afresh from the new contents of buffer-undo-list. > There is only one situation I am aware of where the `undo-tree-canary` > disappears, and it happens sometimes with garbage collection (bug > #27214). Whatever symbol is used, it needs to remain in the > `buffer-undo-list` until `undo-tree-mode` is deactivated. No, it's fine for it to be removed from buffer-undo-list, as long as this only happens when the whole undo history is being discarded. > I suppose the design could have been different, but Dr. Cubitt probably > had several additiona l reasons for using a constant symbol such as the > `undo-tree-canary`. Anything that's an invalid undo entry would do the job. A symbol with the package prefix is the obvious choice. > Bug #16377 might very well be resolvable by tweaking/fixing > undo-tree.el; however, the undo/redo in region code is still a few > light years beyond my present abilities. Unfortunately, it's also always been a few light years beyond my ability to debug :-/ Best, Toby -- Dr T. S. Cubitt Royal Society University Research Fellow Quantum Information Theory Department of Computer Science University College London email: tsc25@cantab.net web: www.dr-qubit.org