Re: outline/allout/overlay performance

[Stefan Monnier]

>> > i think i've surmounted the performance problem i was seeing, by
>> > better stitching together the overlays.
>> Good news.
> but maybe premature - the behaviour "came back".  i will have to
> carefully implement the stitching together stuff before coming to a
> conclusion about viability.

>> [...]
>> > 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?
>> 
>> I don't understand why outline-flag-region should have anything to do with
>> the implementation of an isearch-open-invisible(-temporary) function, so I'm
>> probably not understanding you well, but improving outline-flag-region so it

> the function is registered with the overlay, as a property - that's
> why the current outline-flag-region sets it.  i want to make the
> function it registers with the overlay parameterized - eg, a mode
> local variable - to be registered if set.  outline-mode's current one
> (`outline-isearch-open-invisible') will be used for outline-mode, and
> allout will have its own.  other modes could, too.

Actually, some other modes using similar functions add a few more
properties, so I think it makes sense to just add a &rest parameter to
outline-flag-region.

As for using a buffer-local variable for outline-isearch-open-invisible, it
assumes only one major/minor mode will use it at a time.  In reveal.el
I chose to allow a reveal-toggle-invisible property on the overlay or on the
symbol used for invisibility.  So in outline.el rather than adding the
property to every single overlay, I just do

  (put 'outline 'reveal-toggle-invisible 'outline-reveal-toggle-invisible)

and reveal.el finds it with

  (get (overlay-get ol 'invisible) 'reveal-toggle-invisible)

Maybe isearch (c|sh)ould be changed in a similar way.

>> stitches overlays together sounds like a good idea.
>> Maybe it could be made into a generic function, much like remove-overlays
>> and moved to subr.el.
> i'll take a look at remove-overlays, when i get to that point.

All I was thinking is to add a function like

    (add-overlay-props FROM TO &rest PROPS)

which either creates a new overlay with the specified props or moves
existing overlays if there's already an overlay around with the right
properties, thus trying to minimize the number of overlays in the buffer.
This said, it's probably more important to work on the C code to try and
remove the O(n) behavior.  And even if it's not removed everywhere, I can't
think of any reason why cursor movement should suffer from this
O(n) behavior.


        Stefan