Re: [O] [RFC] Simple cache mechanism for `org-element-at-point'

[Nicolas Goaziou]

Hello,

Carsten Dominik <address@hidden> writes:

> 1. Updating on buffer modification hooks sounds like a very
>    demanding process.

There is obviously a cost, but it shouldn't be very high. I simplified
the process in the announcement. Actually, the cache is not updated
right after each buffer modification. What happens is the following:

  - After each buffer modification, a changeset is stored in
    a buffer-local variable. Building the changeset requires between
    1 and 4 regexp searches between the boundaries of the change.

  - When Emacs is idle cache is updated according to that changeset (see
    `org-element--cache-sync-idle-time') and the changeset is erased.

  - If a modification happens while another previous changeset is still
    present, either changesets are merged into a single one (see
    `org-element--cache-merge-changes-threshold'), or, in the worst
    case, a cache sync is called in order to get rid of the old
    changeset, and the new one is stored.

>    You basically add a third expensive process in addition to font
>    locking and org-indent-mode.

The plan is to use `org-element-at-point' for both of them, so all three
will ultimately become only one process.

>    My worry is that this might be very heavy on Emacs and slow down
>    fast workers. Again, I did not try it, just a worry

It obviously needs to be tested, but I would be surprised if it happened
to be a problem, at least with a compiled Org (no clue on an uncompiled
one).

> 2. Do you expect this to be stable enough to deal with buffers that
>    are invalid in some way or another? Are there any situations in which
>    the parser could fail and leave some weird state behind?

There is nothing invalid at `org-element-at-point' level (i.e. it
shouldn't error, ever). Invalid syntax means that what the parser sees
doesn't match user's expectations. So there is, theoretically, no reason
for the parser to fail. But there are bugs, and only testing will
uncover them.

> 3. Can you explain what you mean by "except in headline-only commands?

`org-element-at-point' is meant to replace all `org-at-...'-like
functions. Calling `org-element-at-point' is like calling all of them at
the same time. It's more expensive than any of them, but returns more
data and is always correct.

But you don't need to know about context to tell if you're one
a headline or not, so `org-at-heading-p' is almost always a superior
choice (unless you need to also retrieve node properties). Likewise, if
you only need to manipulate headlines, you don't need any context
information.


Regards,

-- 
Nicolas Goaziou