From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Three questions about Org-mode API Date: Thu, 15 May 2008 08:58:54 +0200 Message-ID: <8AC86D15-4A7E-4CB8-845B-8AFA355C38AC@gmail.com> References: <1E0F063B-FC61-436F-B5F9-EBAAD47BAD64@science.uva.nl> Mime-Version: 1.0 (Apple Message framework v919.2) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JwXQg-0000jT-73 for emacs-orgmode@gnu.org; Thu, 15 May 2008 02:59:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JwXQe-0000j5-Js for emacs-orgmode@gnu.org; Thu, 15 May 2008 02:59:05 -0400 Received: from [199.232.76.173] (port=45798 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JwXQe-0000j2-F4 for emacs-orgmode@gnu.org; Thu, 15 May 2008 02:59:04 -0400 Received: from mx20.gnu.org ([199.232.41.8]:30049) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JwXQd-0006jq-Lt for emacs-orgmode@gnu.org; Thu, 15 May 2008 02:59:03 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JwXQc-0008Q6-DO for emacs-orgmode@gnu.org; Thu, 15 May 2008 02:59:02 -0400 Received: by ug-out-1314.google.com with SMTP id l31so1516246ugc.48 for ; Wed, 14 May 2008 23:59:00 -0700 (PDT) In-Reply-To: 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: Dmitri Minaev Cc: org-mode Hi Dmitri, On May 12, 2008, at 8:36 PM, Dmitri Minaev wrote: > 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. 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