Re: Three questions about Org-mode API

["Dmitri Minaev" <minaev@gmail.com>]

On Mon, May 12, 2008 at 4:03 PM, Carsten Dominik <dominik@science.uva.nl> wrote:
>  If you are talking only about the standard properties (i.e. not the TODO
> state or the tags, but just the properties in the drawer, the fastest
> inside-org way would be
>
>  (org-entry-get nil 'standard)

No, unfortunately, it won't do. I will need tags, TODO states and
priorities, among other things.

>  If speed is an issue, I would write an external program in perl.
>  I think I could write a perl parser that is at least a factor of 10 faster
>  than anything in emacs lisp.

Perhaps, this is true. But this is my first program in elisp and I
would like to take the chance to learn it :)

What if I ditch the org-mode tools and write a specialized parser in
elisp? My org file has a rather regular structure, with the uniform
properties located in the same order in all entries. Do you think it
would be faster?

>  One could also think of an external database, but that only would work will
> for a linear list of entries, and structure editing does ruin such things.

Hmm... How's that?

Well, what I'm writing is an ebooks catalog. I keep the "database" in
a list. To browse the catalog, I render it into an org-mode-compliant
text buffer and run org-mode. Here I can change tags, priorities, TODO
(toread) state, edit the description and, in some cases, the
information stored in standard properties: title, authors, genre, path
to the file. The database may be rendered in three modes: by title (1
level); by author/title (2 levels) and by genre/author/title (3
levels). When I've done with browsing and editing, I have to convert
the org-mode buffer back into the list. The number of books should be
large enough. As for now, I can deal with 1,000 of them with a
tolerable speed. But I hope to make the library work with up to 10,000
books. So, the list is not linear. And still... An external database?
How?

>  Check out Bastien's parser, I think it is in some branch in the git repo
>  (right Bastien???).  Although I don't know how fast this would be.

Thanks, I'll have a look at it.

> > 3. It would be nice to mark the edited entries as `dirty' to avoid the
> > conversion of non-changed entries. Any ideas?
>
>  This is hard, because you don't want to put any contraints on how the entry
> can be edited.  One could use text properties (during a single session) or
> Org properties, both triggered with after-change-functions, but that is a
> lot of editing overhead.

Could I use some hook that would add an extra property for every changed entry?

-- 
With best regards,
Dmitri Minaev

Russian history blog: http://minaev.blogspot.com