From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Mon, 01 Sep 2008 11:09:04 -0700 Message-ID: <48BC2FC0.90001@emf.net> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220289501 807 80.91.229.12 (1 Sep 2008 17:18:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Sep 2008 17:18:21 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org, bob@rattlesnake.com To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 01 19:19:15 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 1KaD3a-0000IP-Mm for ged-emacs-devel@m.gmane.org; Mon, 01 Sep 2008 19:19:15 +0200 Original-Received: from localhost ([127.0.0.1]:46581 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KaD2b-00012x-K4 for ged-emacs-devel@m.gmane.org; Mon, 01 Sep 2008 13:18:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KaD2X-00012Y-IJ for emacs-devel@gnu.org; Mon, 01 Sep 2008 13:18:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KaD2V-000121-0T for emacs-devel@gnu.org; Mon, 01 Sep 2008 13:18:09 -0400 Original-Received: from [199.232.76.173] (port=44477 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KaD2U-00011y-Qh for emacs-devel@gnu.org; Mon, 01 Sep 2008 13:18:06 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:47606) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KaD2P-00041D-Nl; Mon, 01 Sep 2008 13:18:02 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.75.128] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 38068988; Mon, 01 Sep 2008 10:17:47 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: 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:103374 Archived-At: Richard M. Stallman wrote: > 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. > There is no need to make any decisions in advance. I'm not worried about whether or not the code proves out for GNU Emacs because I am certain I have plenty of uses for it other than that. It might well be good in Emacs. The design is certainly influenced by Emacs' design and experience. It can be hard to compare things like this, I agree. > 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 see any reason that code would *need* to change. It might be *desirable* to change redisplay code if simplifications became possible, or interesting new capabilities. I don't see anything that would *need* to change there. > 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. > You misunderstand how it works. To illustrate: buffer_contents = [some big string]; saved_undo_point = copy (buffer_contents); buffer_contents = insert (buffer_contents, "foobar"); After that code, there are two strings floating around: buffer_contents and saved_undo_point. The two strings differ by the insertion of "foobar" into buffer_contents (or, if you like, the deletion of "foobar" from saved_undo_point). Internally, the two strings share most of their state. The total amount of memory used is (roughly speaking) the memory for saved_undo_point plus the memory for just the string "foobar". So, it is almost exactly the same space consumption as an undo list. (In reality, it's a little bit fancier than what is described above in order to put an upper bound on the amount of fragmentation of strings in memory.) -t > >