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. > 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 _______________________________________________ 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