Hello, Achim Gratz <strom...@nexgo.de> 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… > :-) 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, -- Nicolas Goaziou
