From: Nicolas Goaziou <email@example.com>
To: Eric Abrahamsen <firstname.lastname@example.org>
Subject: Re: problem with org-element-parse-buffer
Date: Sun, 25 Nov 2012 10:11:49 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <firstname.lastname@example.org> (Eric Abrahamsen's message of "Sun, 25 Nov 2012 12:29:26 +0800")
Eric Abrahamsen <email@example.com> writes:
>> Strictly speaking, yes. But Org Agenda is a bit permissive (and not only
>> for that thing). Do you want to help basing Agenda on Elements?
> This is something I was wondering about -- so that is the plan
Since we have a complete parser, it would be good to use it as much as
possible. It will alleviate the need to use regexps and normalize Org
One downside, though, is that it isn't fast enough yet for speed
critical operations (i.e. fontification). A caching mechanism would be
required to go further (any taker?).
Org Elements is quite simple to use: API basically boils down to five
functions. For a global action, the main function to use is
`org-element-parse-buffer'. At the element level (paragraphs,
tables...), it is `org-element-at-point'. At the object level (links,
emphasis...), it is `org-element-context'. Then you extract properties
(resp. type) with `org-element-property' (resp. `org-element-type').
You can get a list of all properties available for each element/object
by looking at:
or by looking at org-element.el source code, obviously.
In order to get started, you can study navigation/manipulation functions
in org.el (from `org-forward-element' to `org-unindent-buffer').
> This is something I've wanted for a while, as it would make
> some of my little personal projects a lot easier. I'd be happy to help
> if there's a roadmap, and if I can be fed bite-sized problems to deal
There's no roadmap for now. If you're looking for small tasks to handle,
I think interactive functions are a good start (although some can be
a bit challenging, i.e. `org-open-link'). Particularly good candidates
are those calling either `org-at-regexp-p', `org-in-regexp' or
`org-between-regexps-p': using those is almost always wrong (or at least
If you give a shot at some of them, please include ert tests: writings
tests for Org is really a must from now on. There are now plenty of
examples in testing directory.
Thank you for your interest in this.
next prev parent reply other threads:[~2012-11-25 9:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-12 9:42 problem with org-element-parse-buffer Peter Münster
2012-11-12 10:55 ` Nicolas Goaziou
2012-11-24 12:00 ` Peter Münster
2012-11-24 12:21 ` Nicolas Goaziou
2012-11-24 22:03 ` Peter Münster
2012-11-25 4:29 ` Eric Abrahamsen
2012-11-25 9:11 ` Nicolas Goaziou [this message]
2012-11-26 1:04 ` Eric Abrahamsen
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).