From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Manheimer Newsgroups: gmane.emacs.devel Subject: Re: outline/allout/overlay performance Date: Thu, 12 Jan 2006 17:40:48 -0500 Message-ID: <2cd46e7f0601121440t14dddf55lcb14b078bd9ecfcf@mail.gmail.com> References: <2cd46e7f0601091127w7f988942w33a105481ccd02e0@mail.gmail.com> <2cd46e7f0601110821x5c97c63bj25d80df70240c80e@mail.gmail.com> <2cd46e7f0601111223m4e568b56n283d038ccfff6be0@mail.gmail.com> <2cd46e7f0601111400j452ee7dexfc79b643ee3655d0@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1137106037 3910 80.91.229.2 (12 Jan 2006 22:47:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 12 Jan 2006 22:47:17 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 12 23:47:17 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ExBDh-0004IY-Fd for ged-emacs-devel@m.gmane.org; Thu, 12 Jan 2006 23:47:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExBFn-0005ab-OV for ged-emacs-devel@m.gmane.org; Thu, 12 Jan 2006 17:49:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ExB9q-0002Rn-Be for emacs-devel@gnu.org; Thu, 12 Jan 2006 17:43:02 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ExB9p-0002RR-KE for emacs-devel@gnu.org; Thu, 12 Jan 2006 17:43:02 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExB9p-0002RM-G9 for emacs-devel@gnu.org; Thu, 12 Jan 2006 17:43:01 -0500 Original-Received: from [66.249.92.205] (helo=uproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ExBCh-0001Pc-LE for emacs-devel@gnu.org; Thu, 12 Jan 2006 17:45:59 -0500 Original-Received: by uproxy.gmail.com with SMTP id u2so271366uge for ; Thu, 12 Jan 2006 14:40:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hNL1tCK5ZOa1fEOCwIt6xrE6zpuZa85jBMECb0KdjWYhT0KBLmfCW+H+7PDQWe5bc0H0/WDUv05cHTpaheeYpKIewEj+Q8ZbrrV0kZbFrEkSLipGqDTEgszI43sSNL1vwcN+kgNnBafEyJjjBqlscx5HLt3Db3y5I2Vr8dpKeMw= Original-Received: by 10.66.255.14 with SMTP id c14mr1013894ugi; Thu, 12 Jan 2006 14:40:48 -0800 (PST) Original-Received: by 10.66.220.6 with HTTP; Thu, 12 Jan 2006 14:40:48 -0800 (PST) Original-To: Stefan Monnier In-Reply-To: Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:48969 Archived-At: 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 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-overl= ays > >> 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