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 14:23:47 -0700 Message-ID: <48BC5D63.4020209@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> <48BC4DF0.3090908@emf.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000907030807080300070201" X-Trace: ger.gmane.org 1220301186 8755 80.91.229.12 (1 Sep 2008 20:33:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Sep 2008 20:33:06 +0000 (UTC) Cc: acm@muc.de, bob@rattlesnake.com, rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 01 22:34:00 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 1KaG5z-0001kZ-4d for ged-emacs-devel@m.gmane.org; Mon, 01 Sep 2008 22:33:55 +0200 Original-Received: from localhost ([127.0.0.1]:37523 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KaG4z-0000U8-QM for ged-emacs-devel@m.gmane.org; Mon, 01 Sep 2008 16:32:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KaG4v-0000Te-25 for emacs-devel@gnu.org; Mon, 01 Sep 2008 16:32:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KaG4t-0000TB-Vd for emacs-devel@gnu.org; Mon, 01 Sep 2008 16:32:48 -0400 Original-Received: from [199.232.76.173] (port=60230 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KaG4t-0000T4-Ri for emacs-devel@gnu.org; Mon, 01 Sep 2008 16:32:47 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:36419) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KaG4o-0007ec-NF; Mon, 01 Sep 2008 16:32:43 -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 38077744; Mon, 01 Sep 2008 13:32:29 -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:103393 Archived-At: This is a multi-part message in MIME format. --------------000907030807080300070201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stefan Monnier wrote: > (I've tried splay-trees for text-properties, and the performance was not > noticeably different from the current mostly-balanced binary tree. > In particular it seems that either we don't get to see the O(1) behavior > because the locality is not as good as it seems, or the constant factor > makes up for the difference). > Thanks for the anecdote. I was kind of thinking that, worst case, that was exactly what to expect and so then, yes, is expected log N good for these purposes? (And I decided, "probably", so I'm coding....) It'll be interesting to see. I think I have an elegant way to do properties and markers but since I haven't coded that part yet I can't swear there isn't a devil in the details. Years ago I did something very close to what I have in mind while working on Guile. (For a while, Guile had an (unreleased) buffer type, with text properties and markers, and a redisplay engine for X11. It was doing OK and might have matured to what I'm thinking of now but that work got interrupted and then bit-rotted away. > >> It *should* (in theory) be just fine for each undo-elt >> to contain both string snapshot(s) and markers that >> track the region effected. That's easy to code and in >> turn it makes undo-elt-in-region very easy to code. >> > > But that would significantly increase the size of the undo log, I expect > (maybe not algorithmically, but by a non-negligible factor). > I guess the way I would say it is that it will *noticably* increase the size of the undo log (yes, by a constant factor). And I would guess that that's *noticably* not *significantly*. We'll see. The library is useful, either way. > It's too bad, because of we ignore the undo-in-region, we don't need > undo info for each modification, we could just grab a snapshot in > undo-boundary. That would be elegant (tho it's not like it matters: > changing the implementation of the undo data is trying to solve > a non-problem, really). > The real problems are a desire for a *nice* unicode-and-text-properties- capable string library with buffer-like capabilities. I want that as a library, first and foremost, not tied to just one program. Thanks, -t > > Stefan > > --------------000907030807080300070201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stefan Monnier wrote:
(I've tried splay-trees for text-properties, and the performance was not
noticeably different from the current mostly-balanced binary tree.
In particular it seems that either we don't get to see the O(1) behavior
because the locality is not as good as it seems, or the constant factor
makes up for the difference).

Thanks for the anecdote.

I was kind of thinking that, worst case, that was exactly
what to expect and so then, yes, is expected log N good
for these purposes?  (And I decided, "probably", so I'm
coding....)

It'll be interesting to see.

I think I have an elegant way to do properties and
markers but since I haven't coded that part yet I
can't swear there isn't a devil in the details. 

Years ago I did something very close to what I
have in mind while working on Guile.   (For a while,
Guile had an (unreleased) buffer type, with text properties
and markers, and a redisplay engine for X11.  It was
doing OK and might have matured to what I'm thinking
of now but that work got interrupted and then bit-rotted
away.




  
It *should* (in theory) be just fine for each undo-elt
to contain both string snapshot(s) and markers that
track the region effected.   That's easy to code and in
turn it makes undo-elt-in-region very easy to code.
    

But that would significantly increase the size of the undo log, I expect
(maybe not algorithmically, but by a non-negligible factor).

I guess the way I would say it is that it will *noticably* increase
the size of the undo log (yes, by a constant factor).    And I would
guess that that's *noticably* not *significantly*.   We'll see.
The library is useful, either way.



It's too bad, because of we ignore the undo-in-region, we don't need
undo info for each modification, we could just grab a snapshot in
undo-boundary.  That would be elegant (tho it's not like it matters:
changing the implementation of the undo data is trying to solve
a non-problem, really).

The real problems are a desire for a *nice* unicode-and-text-properties-
capable string library with buffer-like capabilities.   I want that as a
library, first and foremost, not tied to just one program.


Thanks,
-t




        Stefan

--------------000907030807080300070201--