Re: Release plans

[Thomas Lord]

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






>