From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Keith David Bershatsky Newsgroups: gmane.emacs.bugs Subject: bug#16377: Undo Tree regression: (error "Unrecognized entry in undo list undo-tree-canary") Date: Wed, 05 Jul 2017 23:25:10 -0700 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: blaine.gmane.org 1499322491 19756 195.159.176.226 (6 Jul 2017 06:28:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Jul 2017 06:28:11 +0000 (UTC) Cc: 16377@debbugs.gnu.org, Barry OReilly , Toby Cubitt To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 06 08:28:06 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 1dT0Gk-0004uS-Ew for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Jul 2017 08:28:06 +0200 Original-Received: from localhost ([::1]:49471 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dT0Gp-00050a-UZ for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Jul 2017 02:28:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dT0Gj-00050I-Vo for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2017 02:28:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dT0Gg-0003WY-Qj for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2017 02:28:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51426) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dT0Gg-0003WO-I1 for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2017 02:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dT0Gg-0007MM-6a for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2017 02:28:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Keith David Bershatsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Jul 2017 06:28:02 +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.149932244528248 (code B ref 16377); Thu, 06 Jul 2017 06:28:02 +0000 Original-Received: (at 16377) by debbugs.gnu.org; 6 Jul 2017 06:27:25 +0000 Original-Received: from localhost ([127.0.0.1]:54103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dT0G5-0007LY-DM for submit@debbugs.gnu.org; Thu, 06 Jul 2017 02:27:25 -0400 Original-Received: from gateway32.websitewelcome.com ([192.185.145.113]:35738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dT0G4-0007LQ-1b for 16377@debbugs.gnu.org; Thu, 06 Jul 2017 02:27:24 -0400 Original-Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway32.websitewelcome.com (Postfix) with ESMTP id C94A64584B3 for <16377@debbugs.gnu.org>; Thu, 6 Jul 2017 01:25:11 -0500 (CDT) Original-Received: from gator3053.hostgator.com ([50.87.144.69]) by cmsmtp with SMTP id T0DZdWBkOUy7vT0DZdZV9s; Thu, 06 Jul 2017 01:24:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lawlist.com ; s=default; h=Content-Type:MIME-Version:Subject:Cc:To:From:Message-ID:Date: Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=e9Gw06MmPLyV/EldD/NkDJtCe5HYKDasNKnMlxOIeCI=; b=YEEFLTBT1XjH/Nhyrinunzwpkp wYZwn0oumKC0Nx9R3+fxW5QI5pkMwsef3wIqOCkC2yZZ08Te3DPABkNIaF4fXA2F/VfpEdox5iqd9 DY6Lh3s/er2dTdDfgiIXVjXl6TZMVBL3/WEUPbwoc3SvDRmVmPylDNw/l2B32F+lJckW9asiFnSfv /xQkvZZD4pzcaagL/HlrpGo+3v587c35ONRRa44/ddymAjBV2+Y5wc8lv7u/bTmaw/PDme4sePRAt bdgdblX747BWQ5wkY9lSQlpIFo36L57nCkCmcwWPXo0HCrYKYywIlLSyyaNbzKurbaLzj6rYgpLNs WGPgi0RA==; Original-Received: from cpe-45-48-239-195.socal.res.rr.com ([45.48.239.195]:60164 helo=server.local) by gator3053.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1dT0Dv-000pJ3-19; Thu, 06 Jul 2017 01:25:11 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3053.hostgator.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lawlist.com X-BWhitelist: no X-Source-IP: 45.48.239.195 X-Exim-ID: 1dT0Dv-000pJ3-19 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: cpe-45-48-239-195.socal.res.rr.com (server.local) [45.48.239.195]:60164 X-Source-Auth: lawlist X-Email-Count: 3 X-Source-Cap: bGF3bGlzdDtsYXdsaXN0O2dhdG9yMzA1My5ob3N0Z2F0b3IuY29t 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:134246 Archived-At: Thank you for the helpful critique to substitute `window-buffer` for `get-window-buffer`. I like to keep `debug-on-error` always set to `t`, and known situations I generally limit to showing me just a message in the echo area with the name of the function that generated it. That's why I've been using the `quit` signal instead of popping open a `*Backrace*` buffer for familiar situations. The code that the Emacs team implemented in response to bug#25599 is probably fine. I just hadn't seen that before today, and my code predates its implementation. Substituting the `warn` pop-up buffer for a plain old `message` was just a matter of personal preference. Nothing substantive there was intended. 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. 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`. 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'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`. If the canary is not there, then handle the situation differently. If the canary is there, then process the `buffer-undo-list` until reaching the canary. It could be any arbitrary symbol so long as it remains at the tail end of the `buffer-undo-list` with a `nil` before it while undo-tree is being used in the buffer. There is only one situation I am aware of where the `undo-tree-canary` disappears, and it happens sometimes with garbage collection (bug #27214). Whate ver symbol is used, it needs to remain in the `buffer-undo-list` until `undo-tree-mode` is deactivated. 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`. 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. Keith ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > > + (_ > > + (if (eq next 'undo-tree-canary) > > + (message "undo-tree--primitive-undo: catch-all found `%s'." next) > > + (error "Unrecognized entry in undo list %S" next))))) > > This might make sense to work around the problem, but is clearly not an > actual fix. IIUC Tony said it looked like a bug in undo-tree. > Has there been any progress on finding/fixing the bug there? > What is this "canary" meant to do? If it shouldn't signal an error > here, maybe rather than the constant `undo-tree-canary`, undo-tree > should use another constant value, i.e. one that is a valid (and > harmless) undo entry. > > > Stefan