From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Spiers Subject: Re: FR: headline iteration API Date: Tue, 10 Jun 2008 11:28:44 +0100 Message-ID: <20080610102844.GG5498@atlantic.linksys.moosehall> References: <20080530124619.GB9520@atlantic.linksys.moosehall> <8763spclpm.fsf@gmail.com> Reply-To: Adam Spiers Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K615v-0003GF-DJ for emacs-orgmode@gnu.org; Tue, 10 Jun 2008 06:28:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K615t-0003Fp-KO for emacs-orgmode@gnu.org; Tue, 10 Jun 2008 06:28:50 -0400 Received: from [199.232.76.173] (port=38944 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K615r-0003FY-9m for emacs-orgmode@gnu.org; Tue, 10 Jun 2008 06:28:48 -0400 Received: from mail.beimborn.com ([70.84.38.100]:47350) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K615p-0004iE-UB for emacs-orgmode@gnu.org; Tue, 10 Jun 2008 06:28:46 -0400 Received: from mail.beimborn.com (localhost.localdomain [127.0.0.1]) by mail.beimborn.com (8.12.11.20060308/8.12.8) with ESMTP id m5AASiIO011850 for ; Tue, 10 Jun 2008 05:28:44 -0500 Received: from localhost (localhost [[UNIX: localhost]]) by mail.beimborn.com (8.12.11.20060308/8.12.11/Submit) id m5AASidu011845 for emacs-orgmode@gnu.org; Tue, 10 Jun 2008 11:28:44 +0100 Content-Disposition: inline In-Reply-To: <8763spclpm.fsf@gmail.com> 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: emacs-orgmode@gnu.org On Wed, Jun 04, 2008 at 04:35:01PM +0200, Daniel Clemente wrote: > Hi, > I find this very interesting. Some ideas: >=20 > - Maybe it could provide access not only to the headlines, but to > the headlines of the headlines, and of their headlines, etc. In > fact, access to the whole tree. This would allow batch processing > of any contents. Absolutely - that was a core part of the intent of my proposal; I probably didn't make that clear enough. > As a plus, each header would get a path (like XPath in XML, or DOM > in XHTML) and would be addressable. Maybe useful for links. Whilst borrowing some of the XPath syntax would be an extremely cool way of making content addressable, I do think it's a nice-to-have which is separate to having an iteration API. Maybe later on the API could be extended to only apply to subtrees matching an XPath-like query, but that really would be icing on the cake. I feel that the biggest wins (and very big too, IMHO) would come from a simple iteration API. > - An API would be useful not only to generate reports, etc. like in you= r examples, but also to execute actions on each header; for instance =E2=80= =9Eexport=E2=80=9C each header, =E2=80=9Edelete=E2=80=9C it, ... (And now= with latest version, each header can have different export options) Agreed - it would open up many options for batch processing as well as the reporting examples I gave before. I would personally use it to convert some of my tags into properties. For instance I have tags like 'sub60', 'sub2' to indicate that I estimate a task will take 60 minutes or 2 hours maximum, respectively. They could be converted into the effort estimation property. > - Of course, this is already possible by going through the file looking= for headers; an API would make iteration easier, like with mapcar=20 Yes. There will be many intricacies involved in iteration, and probably only Carsten knows them all - without an API we would individually be reinventing the same wheel over and over ... badly.