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
