emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [RFC] Simple cache mechanism for `org-element-at-point'
Date: Fri, 04 Oct 2013 19:15:31 +0200	[thread overview]
Message-ID: <87hacx7ya4.fsf@gmail.com> (raw)
In-Reply-To: <092FB06C-4326-467A-8033-C7712BEE0AEE@gmail.com> (Carsten Dominik's message of "Fri, 4 Oct 2013 11:13:11 +0200")

Hello,

Carsten Dominik <carsten.dominik@gmail.com> 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

  reply	other threads:[~2013-10-04 17:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-03 21:18 [RFC] Simple cache mechanism for `org-element-at-point' Nicolas Goaziou
2013-10-04  5:43 ` Eric Abrahamsen
2013-10-04  8:53   ` Nicolas Goaziou
2013-10-04  9:13 ` Carsten Dominik
2013-10-04 17:15   ` Nicolas Goaziou [this message]
2013-10-27  8:52 ` Nicolas Goaziou
2013-10-30 10:06   ` Nicolas Goaziou
2013-10-30 12:39     ` Eric Abrahamsen
2013-11-03 12:39       ` Nicolas Goaziou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87hacx7ya4.fsf@gmail.com \
    --to=n.goaziou@gmail.com \
    --cc=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).