Re: existing work on TODO items

[Ken Manheimer]

i have been raising a false alarm.  the performance problems were
being caused by a custom package i was using (vvb-mode) to highlight
long lines - disabling vvb-mode eliminates the problems completely.

i discovered this when i discovered that providing for consolidation
of the overlays didn't help - in fact, the overlays were conslidated
without any special provisions on my part.  this lead me to look at an
'emacs -q' bare environment, and discover it was an interaction with
my customizations that were at fault.

with vvb-mode disabled, there is absolutely no discernable lag,
regardless of the exposure state, when editing my big outline with
invisible-text overlays.

as a side effect, i have converted allout to invisible-text overlays,
and like how it's working, and the simplification of some of the code.
 i'll need to give it time to shake out all the incidental
considerations, but i'm liking how it's looking.

i'm sorry about the false alarm!

ken manheimer
address@hidden

On 1/11/06, Richard M. Stallman <address@hidden> wrote:
>     i noticed that any keystrokes - navigation, inserting text, etc - in
>     an outline-mode buffer with a large amount of collapsed text (closed
>     topics) has severely noticeable latencies.
>
> This is a disturbing problem.  I think we need to make this case
> faster, then.
>
> What is the method that you use in allout.el and runs faster?
> Is it the old selective-display method of changing \n to ^M?
>
> I think there is no fundamental reason that overlays should not be
> just as fast.  Faster, in fact, because if one overlay makes 20 lines
> invisible, it can be skipped without scanning those lines at all.
>
> I don't think we need to do this before the release.
> But it is pretty important to do so.
>