From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Mon, 01 Sep 2008 02:11:27 -0400 Message-ID: References: <878wusz0v9.fsf@uwakimon.sk.tsukuba.ac.jp> <87vdxp27z6.fsf@uwakimon.sk.tsukuba.ac.jp> <87prnxe5hc.fsf@rattlesnake.com> <873aktck5d.fsf@uwakimon.sk.tsukuba.ac.jp> <87k5e5dsvq.fsf@rattlesnake.com> <48B44802.1080302@emf.net> <48B5D5EF.2030501@emf.net> <20080827220906.GB5374@muc.de> <48B5FB11.6090708@emf.net> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1220249656 31942 80.91.229.12 (1 Sep 2008 06:14:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Sep 2008 06:14:16 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org, bob@rattlesnake.com To: Thomas Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 01 08:15:10 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Ka2gu-0003ZZ-1Y for ged-emacs-devel@m.gmane.org; Mon, 01 Sep 2008 08:15:08 +0200 Original-Received: from localhost ([127.0.0.1]:35937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ka2fu-00036j-Vr for ged-emacs-devel@m.gmane.org; Mon, 01 Sep 2008 02:14:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ka2eu-0002kL-Pe for emacs-devel@gnu.org; Mon, 01 Sep 2008 02:13:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ka2eu-0002k0-8v for emacs-devel@gnu.org; Mon, 01 Sep 2008 02:13:04 -0400 Original-Received: from [199.232.76.173] (port=42155 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ka2eu-0002ju-31 for emacs-devel@gnu.org; Mon, 01 Sep 2008 02:13:04 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:59531) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ka2eu-0004oO-93 for emacs-devel@gnu.org; Mon, 01 Sep 2008 02:13:04 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Ka2dL-0005FS-S7; Mon, 01 Sep 2008 02:11:27 -0400 In-reply-to: <48B5FB11.6090708@emf.net> (message from Thomas Lord on Wed, 27 Aug 2008 18:10:41 -0700) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:103358 Archived-At: The string representation is based on splay trees: a string is a splay tree of gap buffers. There are various invariants (that I won't get into here) that make these trees more than ordinary splay trees -- they are a new data structure (afaict). It will not be easy to determine whether this is a better data structure for Emacs, even given a full implementation of it. Even if we had Emacs working using this, it might be hard to tell whether that was an improvement. For instance, many operations might be faster in some cases, and slower in other cases. is an improvement. I also worry that it will be harder for most developers to understand and change -- or even to use. For instance, making redisplay operate on that data structure could be very hard for that reason. I don't think we would want to implement undo by making a snapshot, even if the data makes snapshots possible, because this would take up a lot more space than the current undo data. Snapshots might be useful for something, but not for this.