From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Exporting large documents Date: Tue, 07 May 2013 16:29:52 +0200 Message-ID: <87r4hidfrz.fsf@gmail.com> References: <877gjnojsq.fsf@Rainer.invalid> <5654CA29-5F6D-4E8B-8B8B-C3609D76D189@gmail.com> <8761z5gw6w.fsf@gmx.li> <707EAAA5-D27C-47B7-9A1E-874C3A375BD9@gmail.com> <87zjwcwc4b.fsf@gmx.li> <877gjfgnl9.fsf@gmail.com> <0F877AB5-D488-4223-B0E7-F11B4B973614@gmail.com> <87ip2xfd0x.fsf@gmail.com> <51878F09.1050904@ed.ac.uk> <87vc6wuf0t.fsf@Rainer.invalid> <87haifex41.fsf@gmail.com> <87ip2vvr91.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:33160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZitw-0003Xs-UY for emacs-orgmode@gnu.org; Tue, 07 May 2013 10:30:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZits-0001js-0C for emacs-orgmode@gnu.org; Tue, 07 May 2013 10:29:56 -0400 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:54654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZitr-0001jk-QG for emacs-orgmode@gnu.org; Tue, 07 May 2013 10:29:51 -0400 Received: by mail-wi0-f170.google.com with SMTP id hq12so4039288wib.3 for ; Tue, 07 May 2013 07:29:51 -0700 (PDT) In-Reply-To: <87ip2vvr91.fsf@Rainer.invalid> (Achim Gratz's message of "Mon, 06 May 2013 21:32:26 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Achim Gratz Cc: emacs-orgmode@gnu.org Hello, Achim Gratz writes: > Nicolas Goaziou writes: >> The problem comes from `org-element-at-point'. To be effective, it needs >> to move back to the current headline, and start parsing buffer again >> from there. That means the first element after the headline (often >> a property drawer) will be parsed each time we need information within >> the section. > > What I was suggesting is that we might mark those elements that were > already successfully parsed so that org-element-at-point can just pick > up the markings and only parse again when there are none. Best have > them in the buffer as properties and remove them when an edit is done. Are you talking about text properties? If so, I fail to see how they could be used here. What would you store as a text property? >> A very good improvement for the exporter and, more importantly, for the >> parser, would be to cache results from `org-element--current-element'. >> Though, this cache would also need to be refreshed after each buffer >> modification. This is the tricky part. > > For the exporter we know that the buffer isn't changing, or is it? Of course it is. Macros are expanded, Babel blocks executed, files included. `org-element-at-point' is used between each of these steps. Moreover, a speed-up for `org-element--current-element' has a broader usefulness than just export. >> One solution would be to use `after-change-functions' and >> `before-change-functions' to store intervals of modified areas in the >> buffer. Then, during idle time, a `maphash' could update boundaries of >> cached values or remove them completely, according to the intervals. > > I'd prefer to store this in the buffer, based on no data or experience=E2= =80=A6 > :-) I was thinking about a buffer-local variable storing the cache, and another one storing the intervals. Again, I don't see how text properties could fit in. Regards, --=20 Nicolas Goaziou