* outline/allout/overlay performance (was: existing work on TODO items) [not found] ` <2cd46e7f0601111223m4e568b56n283d038ccfff6be0@mail.gmail.com> @ 2006-01-11 21:51 ` Stefan Monnier 2006-01-11 22:00 ` Ken Manheimer 0 siblings, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2006-01-11 21:51 UTC (permalink / raw) Cc: emacs-devel > i think i've surmounted the performance problem i was seeing, by > better stitching together the overlays. Good news. > 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. You may want to check interaction with reveal-mode 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? 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 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. Stefan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: outline/allout/overlay performance (was: existing work on TODO items) 2006-01-11 21:51 ` outline/allout/overlay performance (was: existing work on TODO items) Stefan Monnier @ 2006-01-11 22:00 ` Ken Manheimer 2006-01-11 22:50 ` outline/allout/overlay performance Stefan Monnier 0 siblings, 1 reply; 11+ messages in thread From: Ken Manheimer @ 2006-01-11 22:00 UTC (permalink / raw) Cc: emacs-devel On 1/11/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > 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. > 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. thanks! ken manheimer ken.manheimer@gmail.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: outline/allout/overlay performance 2006-01-11 22:00 ` Ken Manheimer @ 2006-01-11 22:50 ` Stefan Monnier 2006-01-12 0:59 ` Ken Manheimer 2006-01-12 22:40 ` Ken Manheimer 0 siblings, 2 replies; 11+ messages in thread From: Stefan Monnier @ 2006-01-11 22:50 UTC (permalink / raw) Cc: emacs-devel >> > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: outline/allout/overlay performance 2006-01-11 22:50 ` outline/allout/overlay performance Stefan Monnier @ 2006-01-12 0:59 ` Ken Manheimer 2006-01-12 13:56 ` Thien-Thi Nguyen 2006-01-12 22:40 ` Ken Manheimer 1 sibling, 1 reply; 11+ messages in thread From: Ken Manheimer @ 2006-01-12 0:59 UTC (permalink / raw) Cc: emacs-devel it looks like i was raising a false alarm - the overlays were not the problem, and in fact there was no fragmentation of them. i made a quick consolidating function, only to discover (1) there was no improvement, and (2) actually assessing the extent of the overlays without the consolidation showed that they were not fragmenting. this lead me to suspect my environment, and i discovered that a long-line-highlighting custom package i was using (vvb-mode) was the problem - disabling it totally eliminated any delays. in fact, the side effect of this little adventure is that i'm pretty far along with the conversion to invisibility-overlays, i think the hard things are done (several niggly boundary conditions, isearch fanciness), but will need to shake out the odds and ends, and then work out the common functionality with outline-mode, as stefan and i were discussing. sorry about the false alarm! ken manheimer ken.manheimer@gmail.com On 1/11/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > >> > 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: outline/allout/overlay performance 2006-01-12 0:59 ` Ken Manheimer @ 2006-01-12 13:56 ` Thien-Thi Nguyen 2006-01-12 22:18 ` Ken Manheimer 0 siblings, 1 reply; 11+ messages in thread From: Thien-Thi Nguyen @ 2006-01-12 13:56 UTC (permalink / raw) Cc: Stefan Monnier, emacs-devel Ken Manheimer <ken.manheimer@gmail.com> writes: > and then work out the common functionality with outline-mode, as > stefan and i were discussing. for congruence w/ hideshow, please consider including something similar, in terms of calling convention, to `hs-set-up-overlay' value (see progmodes/hideshow.el). if congruence is not important, then never mind... thi ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: outline/allout/overlay performance 2006-01-12 13:56 ` Thien-Thi Nguyen @ 2006-01-12 22:18 ` Ken Manheimer 2006-01-12 23:30 ` Thien-Thi Nguyen 0 siblings, 1 reply; 11+ messages in thread From: Ken Manheimer @ 2006-01-12 22:18 UTC (permalink / raw) Cc: Stefan Monnier, emacs-devel On 12 Jan 2006 08:56:48 -0500, Thien-Thi Nguyen <ttn@gnu.org> wrote: > Ken Manheimer <ken.manheimer@gmail.com> writes: > > > and then work out the common functionality with outline-mode, as > > stefan and i were discussing. > > for congruence w/ hideshow, please consider including something > similar, in terms of calling convention, to `hs-set-up-overlay' > value (see progmodes/hideshow.el). > > if congruence is not important, then never mind... that looks like a nice feature. i guess you're suggesting that outline-flag-region could enhance the overlays it sets with the presence of some customization variable. for now, however, i'm taking a minimalist approach and sidestepping generalization of outline-flag-region - using it as is, and employing defadvice so that an allout-specific isearch-open-invisible function in allout-mode is in allout-mode. ken manheimer ken.manheimer@gmail.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: outline/allout/overlay performance 2006-01-12 22:18 ` Ken Manheimer @ 2006-01-12 23:30 ` Thien-Thi Nguyen 0 siblings, 0 replies; 11+ messages in thread From: Thien-Thi Nguyen @ 2006-01-12 23:30 UTC (permalink / raw) Cc: emacs-devel Ken Manheimer <ken.manheimer@gmail.com> writes: > that looks like a nice feature. i guess you're suggesting that > outline-flag-region could enhance the overlays it sets with the > presence of some customization variable. close. whether or not `outline-flag-region' enhances the overlays is not my point. rather, that the method for user enhancement of those overlays be similar enough so that (ideally) the function set as the value of one of these variables could be also used as the value of the other. > for now, however, i'm taking a minimalist approach and sidestepping > generalization of outline-flag-region - using it as is, and employing > defadvice so that an allout-specific isearch-open-invisible function > in allout-mode is in allout-mode. IMHO, congruence is a type of long-term minimalism, so we are not so far apart aesthetically as much as temporally... i'm not suggesting generalization of anything. i'm suggesting the conventionalization of `make-overlay' usage in similar (conceptually speaking) contexts. already, hideshow and outline share similar names for similar operations, similar keybindings when using outline as a minor mode, and similar algorithms for setting and tracking parent-child relationships (this last assertion is a guess -- i suspect the set of "tree ops" is not so large as to support wild variability). thi ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: outline/allout/overlay performance 2006-01-11 22:50 ` outline/allout/overlay performance Stefan Monnier 2006-01-12 0:59 ` Ken Manheimer @ 2006-01-12 22:40 ` Ken Manheimer 2006-01-12 23:32 ` Stefan Monnier 2006-01-13 13:07 ` Kim F. Storm 1 sibling, 2 replies; 11+ messages in thread From: Ken Manheimer @ 2006-01-12 22:40 UTC (permalink / raw) Cc: emacs-devel i've made the transition to directly using outline-flag-region from allout mode (rather than allout having it's own allout-flag-region), and am using outline-flag-region as it stands. to enable allout's custom isearch-open-invisible behavior, i'm defadvicing `outline-isearch-open-invisible' (which is what outline-flag-regexp assigns as the isearch-open-invisible property on the overlays) so that allout's preferred function, `allout-show-to-offshoot' is run, instead, when the outline is in allout-mode. this works very nicely! more generally, i'm getting the distinct impression that there are more than a few generalization issues in this suppression-of-detail reveal/conceal realm, that (2) deserve comprehensive attention, and (2) are of scope well beyond the particular things i have time for at the moment. that said, i do have some responses to your particular suggestions. On 1/11/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > 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. i don't like the idea of having every call to outline-flag-region pass in generic mode parameters every time the function is called. such incidental concerns can pile up, obscuring the specific business relevant to the actual call, complicating programmers lives with incidental things to remember in every call. i don't know the exact right mechanism to use for such concerns, but hook-function lists seem like the kind of thing - though we're probably talking about things that belong in particular modes. that suggests properties on some hook variable, qualified with the mode where they belong or put in an 'all' bucket if they want to be used everywhere. > 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. this sounds good - i may be describing something like it, above. > >> 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. fortunately, it doesn't look like overlays need that consolidation. i don't know how they're implemented, but it seems like they "consolidated" on their own. i thank you (and everyone else who've provided clues) for helping guide me. i think i have a good approach at this point - the advice mechnism scales, since others can similarly advice-wrap as needed. it depends on continuing use of the particular outline-isearch-open-invisible function, but any approach is going to establish some such dependencies... ken ken.manheimer@gmail.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: outline/allout/overlay performance 2006-01-12 22:40 ` Ken Manheimer @ 2006-01-12 23:32 ` Stefan Monnier 2006-01-13 13:07 ` Kim F. Storm 1 sibling, 0 replies; 11+ messages in thread From: Stefan Monnier @ 2006-01-12 23:32 UTC (permalink / raw) Cc: emacs-devel > i've made the transition to directly using outline-flag-region from > allout mode (rather than allout having it's own allout-flag-region), > and am using outline-flag-region as it stands. to enable allout's > custom isearch-open-invisible behavior, i'm defadvicing > `outline-isearch-open-invisible' (which is what outline-flag-regexp > assigns as the isearch-open-invisible property on the overlays) so > that allout's preferred function, `allout-show-to-offshoot' is run, > instead, when the outline is in allout-mode. this works very nicely! But doesn't work for reveal-mode which doesn't use outline-isearch-open-invisible. If all you reuse from outline is outline-flag-region, then it really doesn't justify a defadvice. Just copy outline-flag-region into allout-flag-region and modify it: of the 6 lines, one is obsolete and one should be changed (to avoid the ugliness of defavice). Also having your own copy will allow you to use `allout' as the symbol to add to the invisibility-spec, which is cleaner. > fortunately, it doesn't look like overlays need that consolidation. i > don't know how they're implemented, but it seems like they > "consolidated" on their own. Yes, I tried to "consolidate" them in outline as well and then realized that (if you think about it, rather than code blindly, it's pretty obvious) there's never any opportunity for consolidation because the area just before/after the hidden text is always visible (it's a heading). Stefan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: outline/allout/overlay performance 2006-01-12 22:40 ` Ken Manheimer 2006-01-12 23:32 ` Stefan Monnier @ 2006-01-13 13:07 ` Kim F. Storm 2006-01-14 15:24 ` Ken Manheimer 1 sibling, 1 reply; 11+ messages in thread From: Kim F. Storm @ 2006-01-13 13:07 UTC (permalink / raw) Cc: Stefan Monnier, emacs-devel Ken Manheimer <ken.manheimer@gmail.com> writes: > to enable allout's > custom isearch-open-invisible behavior, i'm defadvicing > `outline-isearch-open-invisible' In general, we don't want packages included with emacs to use defadvice. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: outline/allout/overlay performance 2006-01-13 13:07 ` Kim F. Storm @ 2006-01-14 15:24 ` Ken Manheimer 0 siblings, 0 replies; 11+ messages in thread From: Ken Manheimer @ 2006-01-14 15:24 UTC (permalink / raw) Cc: Stefan Monnier, emacs-devel On 1/13/06, Kim F. Storm <storm@cua.dk> wrote: > Ken Manheimer <ken.manheimer@gmail.com> writes: > > > to enable allout's > > custom isearch-open-invisible behavior, i'm defadvicing > > `outline-isearch-open-invisible' > > In general, we don't want packages included with emacs to use > defadvice. ok. i guess i'll do as stefan suggested, and give allout its' own -flag-region routine, etc. (there are attractive reasons to have allout use outline.el's basic routines, but modifying outline.el to provide for this consideration would mean depending on a new version of outline.el, making it yet harder to use allout in older emacs. i, myself, use some systems that are for now held at some older emacs versions, so don't want to go that route.) ken manheimer ken.manheimer@gmail.com ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-01-14 15:24 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <rzqacf3mbav.fsf@albion.dl.ac.uk> [not found] ` <rzq64pmkov4.fsf@albion.dl.ac.uk> [not found] ` <E1EoUi3-0006Vc-DV@fencepost.gnu.org> [not found] ` <rzqek44is9i.fsf@albion.dl.ac.uk> [not found] ` <E1EpzHJ-0000Lk-VC@fencepost.gnu.org> [not found] ` <rzqk6da9ri0.fsf@albion.dl.ac.uk> [not found] ` <E1Ew0Mt-0002aZ-4F@fencepost.gnu.org> [not found] ` <2cd46e7f0601091127w7f988942w33a105481ccd02e0@mail.gmail.com> [not found] ` <E1EwLJV-0005JX-Dc@fencepost.gnu.org> [not found] ` <2cd46e7f0601110821x5c97c63bj25d80df70240c80e@mail.gmail.com> [not found] ` <2cd46e7f0601111223m4e568b56n283d038ccfff6be0@mail.gmail.com> 2006-01-11 21:51 ` outline/allout/overlay performance (was: existing work on TODO items) Stefan Monnier 2006-01-11 22:00 ` Ken Manheimer 2006-01-11 22:50 ` outline/allout/overlay performance Stefan Monnier 2006-01-12 0:59 ` Ken Manheimer 2006-01-12 13:56 ` Thien-Thi Nguyen 2006-01-12 22:18 ` Ken Manheimer 2006-01-12 23:30 ` Thien-Thi Nguyen 2006-01-12 22:40 ` Ken Manheimer 2006-01-12 23:32 ` Stefan Monnier 2006-01-13 13:07 ` Kim F. Storm 2006-01-14 15:24 ` Ken Manheimer
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.