From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dmitri Minaev" Subject: Re: Three questions about Org-mode API Date: Mon, 12 May 2008 23:36:46 +0500 Message-ID: References: <1E0F063B-FC61-436F-B5F9-EBAAD47BAD64@science.uva.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JvctJ-0000zO-Ms for emacs-orgmode@gnu.org; Mon, 12 May 2008 14:36:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JvctH-0000yx-Pm for emacs-orgmode@gnu.org; Mon, 12 May 2008 14:36:53 -0400 Received: from [199.232.76.173] (port=45326 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JvctH-0000ys-Kx for emacs-orgmode@gnu.org; Mon, 12 May 2008 14:36:51 -0400 Received: from mu-out-0910.google.com ([209.85.134.187]:2477) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JvctH-0005Zl-BG for emacs-orgmode@gnu.org; Mon, 12 May 2008 14:36:51 -0400 Received: by mu-out-0910.google.com with SMTP id i2so1267839mue.6 for ; Mon, 12 May 2008 11:36:47 -0700 (PDT) In-Reply-To: <1E0F063B-FC61-436F-B5F9-EBAAD47BAD64@science.uva.nl> Content-Disposition: inline List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: org-mode On Mon, May 12, 2008 at 4:03 PM, Carsten Dominik 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