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: Mon, 2 Jun 2014 12:24:22 -0400 Message-ID: References: <20140602105712.GA8390@c3po.maths.private.cam.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11348774fa1d5304fadcd330 X-Trace: ger.gmane.org 1401726279 30315 80.91.229.3 (2 Jun 2014 16:24:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Jun 2014 16:24:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Toby Cubitt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 02 18:24:34 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 1WrV2F-00076e-8T for ged-emacs-devel@m.gmane.org; Mon, 02 Jun 2014 18:24:31 +0200 Original-Received: from localhost ([::1]:47739 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrV2E-0007EH-OQ for ged-emacs-devel@m.gmane.org; Mon, 02 Jun 2014 12:24:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrV2A-00079G-4Z for emacs-devel@gnu.org; Mon, 02 Jun 2014 12:24:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WrV29-0007uX-1I for emacs-devel@gnu.org; Mon, 02 Jun 2014 12:24:26 -0400 Original-Received: from mail-oa0-x22a.google.com ([2607:f8b0:4003:c02::22a]:36707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrV28-0007rl-RJ for emacs-devel@gnu.org; Mon, 02 Jun 2014 12:24:24 -0400 Original-Received: by mail-oa0-f42.google.com with SMTP id j17so4856966oag.15 for ; Mon, 02 Jun 2014 09:24:23 -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=QP3ny/O8FcAN5ikB9oPEsfeGq5YdMfok1pKwgavzBE8=; b=zAaQf0djKGYvHUdpLCPP9WL/plW9NRuCxa0GZsT6qL+yzUEkykdYzm1iG45elIJy7Q 36FNwsjFm7WNA26j9Efcd7Ax5dyCru4QPTimLmC4f78Z5GwoRaRAoiXFHxP3ceWitVYT +x9e7iu+WIWS+cYTAHyoP+q2z6HJ0nmt2p9p6yTZpZ7U6q6jDBm/6xOT2w/Q3rUlmSiM slPtxJUehL6vXiy3WwKCGzlAtSxm+nm2wnYSAqkbGxjpyPyTw8EU1qGbHzZl058cK+Lb nFysx94KJJYuerKEDD7RaPWw6Z3J/Du1itfMwhLNbQyvLGcrjCxtlvJDmWbKkCyR9Rd0 Rf3w== X-Received: by 10.182.3.10 with SMTP id 10mr39838887oby.22.1401726262863; Mon, 02 Jun 2014 09:24:22 -0700 (PDT) Original-Received: by 10.76.6.44 with HTTP; Mon, 2 Jun 2014 09:24:22 -0700 (PDT) In-Reply-To: <20140602105712.GA8390@c3po.maths.private.cam.ac.uk> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c02::22a 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:172262 Archived-At: --001a11348774fa1d5304fadcd330 Content-Type: text/plain; charset=UTF-8 > I maintain that users are not going to want to hold both models in > their heads. I didn't say users should hold two models in their head. I didn't propose two. > As far as I remember, I've never had anyone ask me if it would be > possible to combine both systems. http://lists.gnu.org/archive/html/gnu-emacs-sources/2009-11/msg00010.html > It's the latter that I predict will be hard work No doubt. > If the two are to coexist, how are the two models of undo going to > interact? You've misunderstood something, see the first answer above. > How will history-discarding work well for both models? Discussed already in the thread. > If you want to integrate undo-tree into Emacs, whilst also keeping > the traditional undo system (presumably an essential requirement), > why not keep the elegant and conceptually simple (biased personal > opinion :-) `buffer-undo-tree's data structure, but make the nodes > point to the appropriate changesets in buffer-undo-list? That may be an option. > That way most of the undo-tree code, including all the tree-related > features, will work unchanged or with very minor changes. I know the value of starting from code that works now. > Reimplementing undo-tree from scratch on top of > undo-(equiv|redo)-table smacks a little of NIH syndrome to me. Nice strawman argument. > I think you're still missing the main point I was making. Because > buffer-undo-tree isn't treated specially by GC, even unreferenced > *deleted* markers (e.g. from `delete-overlay') continued to exist in > the undo-tree. Undoing a changeset containing a marker-update entry > for one of those deleted markers would resurrect the deleted marker, > recreating overlays, and causing general havoc. You may have misattributed the root cause of those problems. --001a11348774fa1d5304fadcd330 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> I maintain that users are not going to want to hold b= oth models in
> their heads.

I didn't say users should hol= d two models in their head. I didn't
propose two.

> As far= as I remember, I've never had anyone ask me if it would be
> possible to combine both systems.

= http://lists.gnu.org/archive/html/gnu-emacs-sources/2009-11/msg00010.html

> It's the latter that I predict will be hard work

No doubt.

> If the two are to coexist, how are the two models= of undo going to
> interact?

You've misunderstood somethi= ng, see the first answer above.

> How will history-discarding wor= k well for both models?

Discussed already in the thread.

> If you want to integrate u= ndo-tree into Emacs, whilst also keeping
> the traditional undo syste= m (presumably an essential requirement),
> why not keep the elegant a= nd conceptually simple (biased personal
> opinion :-) `buffer-undo-tree's data structure, but make the nodes=
> point to the appropriate changesets in buffer-undo-list?

Th= at may be an option.

> That way most of the undo-tree code, inclu= ding all the tree-related
> features, will work unchanged or with very minor changes.

I kno= w the value of starting from code that works now.

> Reimplementin= g undo-tree from scratch on top of
> undo-(equiv|redo)-table smacks a= little of NIH syndrome to me.

Nice strawman argument.

> I think you're still missing th= e main point I was making. Because
> buffer-undo-tree isn't treat= ed specially by GC, even unreferenced
> *deleted* markers (e.g. from = `delete-overlay') continued to exist in
> the undo-tree. Undoing a changeset containing a marker-update entry> for one of those deleted markers would resurrect the deleted marker,<= br>> recreating overlays, and causing general havoc.

You may have= misattributed the root cause of those problems.

--001a11348774fa1d5304fadcd330--