* org-map-entries and org-map-continue-from
@ 2011-02-28 18:40 Richard Lawrence
2011-02-28 19:02 ` Nick Dokos
0 siblings, 1 reply; 4+ messages in thread
From: Richard Lawrence @ 2011-02-28 18:40 UTC (permalink / raw)
To: emacs-orgmode
Hi all,
Bastien had advised me [1] to use
(setq org-map-continue-from (outline-next-heading))
in a function called by org-map-entries in order to map that function
across just the /children/ of the current entry (i.e., to exclude the
current `parent' entry itself). This works great, but I have now found
that it has a weird side-effect: it calls the function twice on the last
child.
For a simple example, suppose I write:
#+BEGIN_SRC emacs-lisp
(defun get-export-filenames ()
(interactive)
(setq export-files '())
(progn
(org-map-entries
(lambda ()
(setq org-map-continue-from (outline-next-heading))
(let ((org-trust-scanner-tags t))
(push (org-entry-get (point) "EXPORT_FILE_NAME") export-files)))
nil 'tree)
(message export-files))) ; errors, but lets me see the list of collected values
#+END_SRC
And I call this function from a buffer that looks like:
* Top
<point is here when I call get-export-filenames>
** One
:PROPERTIES:
:EXPORT_FILE_NAME: one
:END:
** Two
:PROPERTIES:
:EXPORT_FILE_NAME: two
:END:
** Three
:PROPERTIES:
:EXPORT_FILE_NAME: three
:END:
** Four
:PROPERTIES:
:EXPORT_FILE_NAME: four
:END:
Then the list that I get back (the value of export-files) looks like:
("four" "four" "three" "two" "one")
Whereas I would like it to be just:
("four" "three" "two" "one")
Can anyone see what I need to do to achieve that? [Apart from just using
(cdr export-files), I mean -- I'd like to know the /right/ way.] I'm
puzzled because outline-next-heading, if called interactively from the
last child, does indeed put point at the end of that child or at the
next (parent-level) heading, so it doesn't seem that the problem is that
it somehow loops back when there is no next child-level entry.
Many thanks if you catch something I've missed!
Best,
Richard
[1] http://article.gmane.org/gmane.emacs.orgmode/37244/
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: org-map-entries and org-map-continue-from
2011-02-28 18:40 org-map-entries and org-map-continue-from Richard Lawrence
@ 2011-02-28 19:02 ` Nick Dokos
2011-02-28 19:14 ` Nick Dokos
0 siblings, 1 reply; 4+ messages in thread
From: Nick Dokos @ 2011-02-28 19:02 UTC (permalink / raw)
To: Richard Lawrence; +Cc: nicholas.dokos, emacs-orgmode
Richard Lawrence <richard.lawrence@berkeley.edu> wrote:
> For a simple example, suppose I write:
> #+BEGIN_SRC emacs-lisp
> (defun get-export-filenames ()
> (interactive)
> (setq export-files '())
> (progn
> (org-map-entries
> (lambda ()
> (setq org-map-continue-from (outline-next-heading))
> (let ((org-trust-scanner-tags t))
> (push (org-entry-get (point) "EXPORT_FILE_NAME") export-files)))
> nil 'tree)
> (message export-files))) ; errors, but lets me see the list of collected values
> #+END_SRC
>
As you point out below, everything works as it should: outline-next-heading
steps you through the headlines and eventually returns nil
correctly. The problem is that org-entry-get does not just look forward:
it looks *around* and finds the property when point is both at the
beginning and at the end of the headline "Four", so you get "four"
twice.
But I'm not sure what the right way to deal with it is.
Nick
> And I call this function from a buffer that looks like:
>
> * Top
> <point is here when I call get-export-filenames>
> ** One
> :PROPERTIES:
> :EXPORT_FILE_NAME: one
> :END:
> ** Two
> :PROPERTIES:
> :EXPORT_FILE_NAME: two
> :END:
> ** Three
> :PROPERTIES:
> :EXPORT_FILE_NAME: three
> :END:
> ** Four
> :PROPERTIES:
> :EXPORT_FILE_NAME: four
> :END:
>
> Then the list that I get back (the value of export-files) looks like:
>
> ("four" "four" "three" "two" "one")
>
> Whereas I would like it to be just:
>
> ("four" "three" "two" "one")
>
> Can anyone see what I need to do to achieve that? [Apart from just using
> (cdr export-files), I mean -- I'd like to know the /right/ way.] I'm
> puzzled because outline-next-heading, if called interactively from the
> last child, does indeed put point at the end of that child or at the
> next (parent-level) heading, so it doesn't seem that the problem is that
> it somehow loops back when there is no next child-level entry.
>
> Many thanks if you catch something I've missed!
>
> Best,
> Richard
>
> [1] http://article.gmane.org/gmane.emacs.orgmode/37244/
>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: org-map-entries and org-map-continue-from
2011-02-28 19:02 ` Nick Dokos
@ 2011-02-28 19:14 ` Nick Dokos
2011-03-01 4:01 ` Richard Lawrence
0 siblings, 1 reply; 4+ messages in thread
From: Nick Dokos @ 2011-02-28 19:14 UTC (permalink / raw)
To: nicholas.dokos; +Cc: Richard Lawrence, emacs-orgmode
Nick Dokos <nicholas.dokos@hp.com> wrote:
> Richard Lawrence <richard.lawrence@berkeley.edu> wrote:
>
>
> > For a simple example, suppose I write:
> > #+BEGIN_SRC emacs-lisp
> > (defun get-export-filenames ()
> > (interactive)
> > (setq export-files '())
> > (progn
> > (org-map-entries
> > (lambda ()
> > (setq org-map-continue-from (outline-next-heading))
> > (let ((org-trust-scanner-tags t))
> > (push (org-entry-get (point) "EXPORT_FILE_NAME") export-files)))
> > nil 'tree)
> > (message export-files))) ; errors, but lets me see the list of collected values
> > #+END_SRC
> >
>
> But I'm not sure what the right way to deal with it is.
>
Maybe this?
--8<---------------cut here---------------start------------->8---
#+BEGIN_SRC emacs-lisp
(defun get-export-filenames ()
(interactive)
(setq export-files '())
(progn
(org-map-entries
(lambda ()
(setq org-map-continue-from (outline-next-heading))
(if org-map-continue-from
(let ((org-trust-scanner-tags t))
(push (org-entry-get (point) "EXPORT_FILE_NAME") export-files))))
nil 'tree)
(message export-files))) ; errors, but lets me see the list of collected values
#+END_SRC
--8<---------------cut here---------------end--------------->8---
Nick
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: org-map-entries and org-map-continue-from
2011-02-28 19:14 ` Nick Dokos
@ 2011-03-01 4:01 ` Richard Lawrence
0 siblings, 0 replies; 4+ messages in thread
From: Richard Lawrence @ 2011-03-01 4:01 UTC (permalink / raw)
To: emacs-orgmode
Nick Dokos <nicholas.dokos@hp.com> writes:
> The problem is that org-entry-get does not just look forward: it looks
> *around* and finds the property when point is both at the beginning
> and at the end of the headline "Four", so you get "four" twice.
Ah, so that's the culprit. Thanks!
> Maybe this?
>
> #+BEGIN_SRC emacs-lisp
> (defun get-export-filenames ()
> (interactive)
> (setq export-files '())
> (progn
> (org-map-entries
> (lambda ()
> (setq org-map-continue-from (outline-next-heading))
> (if org-map-continue-from
> (let ((org-trust-scanner-tags t))
> (push (org-entry-get (point) "EXPORT_FILE_NAME") export-files))))
> nil 'tree)
> (message export-files))) ; errors, but lets me see the list of collected values
>
> #+END_SRC
Indeed, that does seem to work: outline-next-heading returns nil if it
doesn't find a next heading, and a buffer location otherwise (at least
that's the way it looks based on some tests; the documentation doesn't
say, and I didn't crack open the code). So wrapping the rest of the
lambda body in (if org-map-continue-from ...) prevents it from executing
that one last time.
Thanks for your help, Nick!
Best,
Richard
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-03-01 3:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-28 18:40 org-map-entries and org-map-continue-from Richard Lawrence
2011-02-28 19:02 ` Nick Dokos
2011-02-28 19:14 ` Nick Dokos
2011-03-01 4:01 ` Richard Lawrence
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).