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 <[EMAIL PROTECTED]> 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? _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
