From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#16411: undo-only bugs Date: Thu, 15 May 2014 09:00:24 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1400158892 1743 80.91.229.3 (15 May 2014 13:01:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 May 2014 13:01:32 +0000 (UTC) Cc: 16411 <16411@debbugs.gnu.org> To: Barry OReilly Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 15 15:01:25 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 1WkvHl-0004iN-LD for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 May 2014 15:01:21 +0200 Original-Received: from localhost ([::1]:57943 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkvHl-0003d6-Ap for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 May 2014 09:01:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkvHZ-0003Rv-Uc for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 09:01:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkvHS-0007u3-FQ for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 09:01:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkvHS-0007tr-88 for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 09:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WkvHR-0002Kc-KN for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 09:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 May 2014 13:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16411 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16411-submit@debbugs.gnu.org id=B16411.14001588328909 (code B ref 16411); Thu, 15 May 2014 13:01:01 +0000 Original-Received: (at 16411) by debbugs.gnu.org; 15 May 2014 13:00:32 +0000 Original-Received: from localhost ([127.0.0.1]:35476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkvGw-0002JZ-E0 for submit@debbugs.gnu.org; Thu, 15 May 2014 09:00:31 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:41814) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkvGt-0002JN-5C for 16411@debbugs.gnu.org; Thu, 15 May 2014 09:00:28 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s4FD0OQ8019941; Thu, 15 May 2014 09:00:25 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 4DD35600DB; Thu, 15 May 2014 09:00:24 -0400 (EDT) In-Reply-To: (Barry OReilly's message of "Wed, 14 May 2014 23:51:05 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4942=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4942> : inlines <871> : streams <1183534> : uri <1757418> 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:89127 Archived-At: >> If anything should be done with it, I think it'd be to *cut* the >> extra undo/redo pairs. > No complaint from me. That would change the behavior of ordinary undo > command, Yes. And I think that's what we want: as a user, having to wade through N repetitions of redo/undo is a pain. Those that suffer often from it probably switched to undo-tree. The idea of cutting the extra undo-redo pairs follows the following principle: an undo-redo pair gives you access to 1 past buffer state, but if the earlier undo elements already made you go through an identical state, then this undo-redo pair is superfluous. I'm sure this can be generalized for undo-in-region (where an undo-redo pair may not bring you exactly to the same state, but still gives you access to a change you've already seen earlier in the undo list), but I'm sure you can define it more easily than I. > which you just said you don't want to change. So far there was no discussion of changing behavior: only fixing bugs and changing implementation. >> I'm not completely convinced that this generator is worthwhile > Ok, I'll lose it then. We may want to (re)introduce it later, tho. >>> I originally set out to do this, but making the weak references >>> work seemed overly tricky to me. The value stored in >>> undo-redo-table would need to be non weak with weak references to >>> undo elements. I supposed this would mean many one element weak >>> hash tables. That seems dodgy. >> Hmm... that's a very good point. Worth mentioning in a comment. > You actually want me to do that? That is: wrap every referenced > element in a size 1 weak hash table. God no! I'm saying that I agree with your justification for the design of undo-redo-table keeping mappings for every undo-element rather than one per undo group; but that you need to put a comment in the code explaining why it's done this way. Stefan