[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orgmode] Three questions about Org-mode API
From: |
Dmitri Minaev |
Subject: |
Re: [Orgmode] Three questions about Org-mode API |
Date: |
Mon, 12 May 2008 23:36:46 +0500 |
On Mon, May 12, 2008 at 4:03 PM, Carsten Dominik <address@hidden> 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