Hi Dmitri,
On May 12, 2008, at 8:36 PM, Dmitri Minaev wrote:
On Mon, May 12, 2008 at 4:03 PM, Carsten Dominik <[EMAIL PROTECTED]
> 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.
OK.
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 :)
That is certainly a good opportunity to learn this stuff.
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?
Yes, I think it would be faster. Maybe a factor 2-3? Not much more
(I hope, or my code is really bad :-)
I think if you search for org-complex-heading-regexp and use that to
extract TODO state, level, priority, heading text, this will already
be more efficient than getting the special properties through calling
org-entry-properties, because you get it in a single match.
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?
What I meant to say: One could keep all the stuf in a database, and
then pull out individual entries to edit them. The problems with such
an approach is that
- You loose structure information from an outline structure in the org
file
- You only get to edit individual entries
If you like the convenience of having the whole ting in a single file
to edit it, this is not a solution, I agree.
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?
As I said, this would have to be after-change-functions. Check out
the Elisp documentation for this hook.
- Carsten
_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
