From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry OReilly Newsgroups: gmane.emacs.devel Subject: Re: Integration of undo-tree in Emacs Date: Wed, 28 May 2014 22:57:15 -0400 Message-ID: References: <20140528221435.GA24032@c3po> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bd6b3fc1f1d9d04fa811696 X-Trace: ger.gmane.org 1401332251 5473 80.91.229.3 (29 May 2014 02:57:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 May 2014 02:57:31 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Toby Cubitt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 29 04:57:25 2014 Return-path: Envelope-to: ged-emacs-devel@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 1WpqWv-00043b-Vd for ged-emacs-devel@m.gmane.org; Thu, 29 May 2014 04:57:22 +0200 Original-Received: from localhost ([::1]:45865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WpqWv-00038z-LM for ged-emacs-devel@m.gmane.org; Wed, 28 May 2014 22:57:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WpqWr-00038u-R6 for emacs-devel@gnu.org; Wed, 28 May 2014 22:57:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WpqWq-0001R3-LR for emacs-devel@gnu.org; Wed, 28 May 2014 22:57:17 -0400 Original-Received: from mail-ob0-x233.google.com ([2607:f8b0:4003:c01::233]:39717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WpqWq-0001Qw-BW for emacs-devel@gnu.org; Wed, 28 May 2014 22:57:16 -0400 Original-Received: by mail-ob0-f179.google.com with SMTP id vb8so11683193obc.38 for ; Wed, 28 May 2014 19:57:15 -0700 (PDT) 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 :cc:content-type; bh=O//bLTIYmgPOX+EodbtG8e5ijx/QVhgJTAcj3oeNVio=; b=yhv2+eZX+auLJpB8HzpoopShWPiA4osjpXO4jcBttLzvW9y4wGDYDXUZuyAWinHn6A eam1fZ39wbC+7wBZWjqRynWzKFGSEW8eSNn35taYMKCd5NShdL2jrISng+nXh/HjGKd9 ugA1ddb5dBpH0PtXcA5NypapTcA8rm/1fnjHdN+grN/1ZQByEFR0ySnscEkp520yY/UT iIbMfUv0YbijSpFEeMg05f0S4EgIie9dNV05JHJEwbRIKzoxugcnai8af0YrwkjIBmQW gCN4oEJHCDeHgtlV3aVOZ5Y+AY9nTxt09aCzx9bPkIXNQqFgiP3RDTkmsR3OXcZsnzuL I8sw== X-Received: by 10.60.156.103 with SMTP id wd7mr4728899oeb.4.1401332235703; Wed, 28 May 2014 19:57:15 -0700 (PDT) Original-Received: by 10.76.6.44 with HTTP; Wed, 28 May 2014 19:57:15 -0700 (PDT) In-Reply-To: <20140528221435.GA24032@c3po> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172169 Archived-At: --047d7bd6b3fc1f1d9d04fa811696 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your reply, Toby. I appreciate your wisdom on this topic. > Perhaps I felt that duplicating the entire subtree would make for a > needlessly complex tree. I find one limitation in undo-tree is that a buffer state that was two edges away becomes an arbitrary number of edges away, because undo in region reaches arbitrarily far back. Alternatively, after an undo in region, you could display it like: | | A' |\=E2=80=A6 | Literally with the ellipsis. Traversing that edge would take you back to the parallel tree you came from: | =E2=80=A6 |/ A | | The parallel trees look the same after all. I don't think the user usually cares where is the root at which they join together, although there are probably ways to display that. > The implementation and maintenance overhead of designing a system > that simultaneously supports two largely incompatible undo models > doesn't seem worth it to me. I'm not sure why you say they're largely incompatible. > From memory (and git logs), I think that without this mechanism > undo-tree used to sometimes resurrect dead markers when undoing. A > lisp package might delete a marker from a buffer and drop all > references to it, expecting it to be garbage collected. But because > it was referenced from buffer-undo-tree (a strong reference, rather > than the specialized buffer-undo-list weak reference), the marker > never got GCd. Undoing a changeset containing the deleted marker > would then restore the marker. I remember this created all kinds of > havoc with overlays. Sounds like bug 16818, which affected the builtin undo system too. It is fixed in the upcoming Emacs 24.4. undo-tree may require an analagous change, since it doesn't use undo-make-selective-list. I don't think this bug has anything particular to do with compact_undo_list splicing out marker adjustments in GC. Maybe the undo-tree-object-pool makes the bug less probable because it allows some problematic marker adjustments to be removed earlier during GC instead of later during undo history truncation. The undo-tree-object-pool code looks like a correct, albeit convoluted, mimicry of compact_undo_list, but I don't see an actual problem either solves. --047d7bd6b3fc1f1d9d04fa811696 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your reply, Toby. I appreciate your wisdom on t= his topic.

> Perhaps I felt that duplicating the entire subtree w= ould make for a
> needlessly complex tree.

I find one limitati= on in undo-tree is that a buffer state that was two
edges away becomes an arbitrary number of edges away, because
undo in re= gion reaches arbitrarily far back.

Alternatively, after an undo in r= egion, you could display it like:

=C2=A0 |
=C2=A0 |
=C2=A0 A'
=C2=A0 |\=E2=80=A6
=C2=A0 |

L= iterally with the ellipsis. Traversing that edge would take you back
to = the parallel tree you came from:

=C2=A0 | =E2=80=A6
=C2=A0 |/
=C2=A0 A
=C2=A0 |
=C2=A0 |

The parallel trees look the = same after all. I don't think the user
usually cares where is the ro= ot at which they join together, although
there are probably ways to disp= lay that.

> The implementation and maintenance overhead of designing a system<= br>> that simultaneously supports two largely incompatible undo models> doesn't seem worth it to me.

I'm not sure why you say= they're largely incompatible.

> From memory (and git logs), I think that without this mechanism> undo-tree used to sometimes resurrect dead markers when undoing. A> lisp package might delete a marker from a buffer and drop all
> references to it, expecting it to be garbage collected. But because> it was referenced from buffer-undo-tree (a strong reference, rather> than the specialized buffer-undo-list weak reference), the marker > never got GCd. Undoing a changeset containing the deleted marker
&g= t; would then restore the marker. I remember this created all kinds of
&= gt; havoc with overlays.

Sounds like bug 16818, which affected the b= uiltin undo system too. It
is fixed in the upcoming Emacs 24.4. undo-tree may require an
analagous = change, since it doesn't use undo-make-selective-list.

I don'= ;t think this bug has anything particular to do with
compact_undo_list s= plicing out marker adjustments in GC. Maybe the
undo-tree-object-pool makes the bug less probable because it allows
some= problematic marker adjustments to be removed earlier during GC
instead = of later during undo history truncation.

The undo-tree-object-pool c= ode looks like a correct, albeit
convoluted, mimicry of compact_undo_list, but I don't see an actual
= problem either solves.

--047d7bd6b3fc1f1d9d04fa811696--