"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Hrvoje> Except they're slow and buggy. Always have been.
The "buggy" I can't speak to.
As usual, the FSF implementation has idiosyncrasies we don't copy.
But there have been real bugs, too.
"Slow" is (AFAIK) a function of needing to coalesce and
extents due to deletion or addition of text lacking the property of
the surrounding text.
Not only that. The extents code was never really optimized for what
the text property code is trying to do. (There have been attempts;
that's why some of the textprop functions are in C.) Ben once
explained what needed to be done to make the textprops code fast, and
it sounded like several days' work. Not too hard, but not something
you'd do unless you're very motivated, either.
Programs making heavy use of text properties will notice the slowness,
and it's a real problem.
But extents themselves can be extremely slow if you aren't
"in display order".
Display order is not only about ordering; it allows the code that
locates extents to fetch them in logarithmic time using binary search.
You have to be pretty imaginative to make extents "extremely slow",
and the text properties code seems to have exactly that kind of
Hrvoje> More and more packages are using overlays, which also
Hrvoje> goes to show that text properties are not as useful as
Hrvoje> Stallman has made them out to be.
Big surprise there. I agree with rms that they are quite useful in
They are, but they carry a lot of unnecessary baggage with them. If
all you need is to show something resembling a GUI button (see Gnus),
or mark a region of text and store the pointer to the "marker",
extents are the thing for you. This fits the usage pattern of a
surprising number of applications.