Re: Exporting large documents

[Nicolas Goaziou <n.goaziou@gmail.com>]

Hello,

Achim Gratz <Stromeko@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