emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release plans


From: Thomas Lord
Subject: Re: Release plans
Date: Mon, 01 Sep 2008 14:23:47 -0700
User-agent: Thunderbird 1.5.0.5 (X11/20060808)

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

  


reply via email to

[Prev in Thread] Current Thread [Next in Thread]