Re: existing work on TODO items

[Ken Manheimer]

i think i've surmounted the performance problem i was seeing, by
better stitching together the overlays.

where i'm getting to is a version of allout that uses a routine which
flags text for invisibility that is very like the one in outline-mode
- `outline-flag-region' - but uses a different routine to reconcile
the presentation after isearches - the `isearch-open-invisible'
property.  i may want to use a special
`isearch-open-invisible-temporary' property, as well.  these choices
are hard-coded in the current `outline-flag-region', so i can't use it
as stands.  i could suggest a slightly modified version which
open-codes these choices so "derivative" outline modes can use it
directly while tailoring these aspects for their specific purposes. 
does that seem like a reasonable way to go?

and, stepping back a bit, should i be asking these questions in this
context, or in emacs-devel?

On 1/11/06, Ken Manheimer <address@hidden> wrote:

> [...]
> the issue here is that the problem appears to be with the use of
> invisible-text overlays.  i have made some exploratory adjustments to
> allout to use invisible overlays instead of selective display, and am
> noticing similar delays - one second per character, rather than
> between two and three seconds that i noticed in outline-mode.
>
> these delays would cripple my most frequent editing activity - adding
> notes to my daily log - and in general would reduce the scale of
> outlines that i could edit.
> [...]
> one thing i wonder is whether the delays might depend on the number of
> overlays? if so, and if it's not already happening, it might
> significantly reduce the problem to have adjacent overlays
> automatically consolidated so that the total number of them is kept to
> a minimum.  is there any conventional experience with and wisdom about
> the dynamics of overlays, in this regard?