From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eddward DeVilla" Subject: Re: FR: headline iteration API Date: Wed, 11 Jun 2008 20:09:50 -0500 Message-ID: References: <20080530124619.GB9520@atlantic.linksys.moosehall> <9592BB6CDB1CEB48826BE86ACD71FA996ABF8D@kwik.ic.uva.nl> <20080611110623.GC19396@atlantic.linksys.moosehall> 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 1K6bK5-0005hp-Gc for emacs-orgmode@gnu.org; Wed, 11 Jun 2008 21:09:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K6bK4-0005h7-0r for emacs-orgmode@gnu.org; Wed, 11 Jun 2008 21:09:53 -0400 Received: from [199.232.76.173] (port=35107 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K6bK3-0005h1-Os for emacs-orgmode@gnu.org; Wed, 11 Jun 2008 21:09:51 -0400 Received: from wf-out-1314.google.com ([209.85.200.168]:51787) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K6bK3-0001oP-9f for emacs-orgmode@gnu.org; Wed, 11 Jun 2008 21:09:51 -0400 Received: by wf-out-1314.google.com with SMTP id 28so3436556wfc.24 for ; Wed, 11 Jun 2008 18:09:50 -0700 (PDT) In-Reply-To: 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: Adam Spiers , org-mode mailing list On Wed, Jun 11, 2008 at 12:15 PM, Eddward DeVilla wrote: > Are the functions behind C-c C-N, C-c C-p, C-c C-f, C-c C-b & C-c C-u > available? Seems you could add a function for going to the first > child. As long as that, C-c C-f & C-c C-b all return something to let > you know there isn't a next, this should be pretty complete. > > I guess all you would need would be the following functions which > would move to the correct place or return something to say there isn't > a next/parent/child/sibling etc to signal the end of iteration. > > - doc traversal > - first-item > Go to the first item in the file. > - current-item > Go to the beginning of the item containing the cursor. > - next-item > Go to the item after the current one. > - previous-item > Go to item before the current one > > - tree traversal > - parent-item > Go to the parent item of the current item > - first-child-item > Go to the first item contained in the current item > - next-sibling-item > Go to the next item that has the same parent > - previous-sibling-item > Go to the previous item that has the same parent > > This ought to be enough to try to implement anything else on top of > it. Did I miss something? Just to respond to myself, I did miss something. If we want a convenient base api, we probably ought to have an equivalent to the doc traversal functions for iterating through all the items in the agenda files. I'm not sure what the correct behavior should be in that case if you start in a file that is not in the list of agenda files. I was precise about the sibling functions to handle the following if you call next-sibling-item from meanie. * eenie *** meanie ** minie * Hey Moe! Edd