From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: Exporting large documents Date: Mon, 06 May 2013 21:32:26 +0200 Message-ID: <87ip2vvr91.fsf@Rainer.invalid> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:52489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZR9S-0006yC-6B for emacs-orgmode@gnu.org; Mon, 06 May 2013 15:32:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZR9Q-0006VZ-LF for emacs-orgmode@gnu.org; Mon, 06 May 2013 15:32:46 -0400 Received: from plane.gmane.org ([80.91.229.3]:46163) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZR9Q-0006VL-F6 for emacs-orgmode@gnu.org; Mon, 06 May 2013 15:32:44 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UZR9O-0006my-1b for emacs-orgmode@gnu.org; Mon, 06 May 2013 21:32:42 +0200 Received: from pd9eb104a.dip0.t-ipconnect.de ([217.235.16.74]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 May 2013 21:32:42 +0200 Received: from Stromeko by pd9eb104a.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 May 2013 21:32:42 +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: emacs-orgmode@gnu.org Nicolas Goaziou writes: > Actually this is a bit different. Parsing doesn't backtrack. Look at > `org-element-parse-buffer' through elp to see that elements are parsed > only once. Sorry for the loose terminology. > 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. > 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? > 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… :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada