emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* bugs in property searches?
@ 2014-01-29  2:00 John Kitchin
  2014-01-29  5:05 ` Nick Dokos
  0 siblings, 1 reply; 3+ messages in thread
From: John Kitchin @ 2014-01-29  2:00 UTC (permalink / raw)
  To: emacs-orgmode

Hi Everyone,

I am experimenting with using an org-file as a database of sorts. The
idea is to have some heading like this that represent courses, with
various classifications (tags) and properties. Then, I would generate
reports on these headings. I have run across to behaviors that seem like
bugs to me. 
1. the point moves in org-map-entries, and I thought it would not since
the documentation says the function is wrapped in save-excursion. This
lead to the results going in the wrong place. 

2. In using a PROPERTY search, headings that did not have the property
got "mapped".Scroll past these to see what I mean.

My org-file is essentially like this. It is part of a bigger file, which
I have narrowed to this subtree.

* Using org-mode files as databases

For example, this code gives me a list of classes that are tagged
chemistry|biology|physics|math, and the total units

#+BEGIN_SRC emacs-lisp 
(let* ((total-units 0) 
      (units) 
      (course)
      (courses (org-map-entries (lambda ()
				  (setq units (string-to-number (org-entry-get (point) "UNITS"))
					total-units (+ total-units units)
					course (nth 4 (org-heading-components)))
				  `(,course  ,units ,(org-entry-get (point) "SEMESTER")))
				"chemistry|biology|physics|math" 'tree nil)))
  (add-to-list 'courses `(nil "Total units"  ,total-units) t))
#+END_SRC

#+RESULTS:
| 09-105 |           9 |  1 |
| 09-106 |           9 |  2 |
| 33-105 |          12 |  1 |
| 33-106 |          12 |  3 |
| 21-120 |           9 |  1 |
| 21-122 |           9 |  2 |
| 21-259 |           9 |  3 |
| 03-232 |           9 |  5 |
|    nil | Total units | 78 |

That seems correct.

But I noticed that when I run the block, the cursor ends up at the top
of the narrowed region at the top headline, and I thought it should stay
in the source block since org-map-entries claims to save-excursion.

Things get stranger if I add a second source block below this. Here I
thought I would get a list of classes with less than 12 UNITS, which are
properties. 

#+BEGIN_SRC emacs-lisp
(org-map-entries (lambda () 
		   (let ((heading (nth 4 (org-heading-components)))
			 (units (org-entry-get (point) "UNITS")))
		     `(,heading  ,units)))
		 "UNITS<12" 'tree nil)
#+END_SRC

The results is almost right:

#+RESULTS:
| Using org-mode files as databases | nil |
|                            09-105 |   9 |
|                            09-106 |   9 |
|                            21-120 |   9 |
|                            21-122 |   9 |
|                            21-259 |   9 |
|                            03-232 |   9 |

I was surprised to see the nil in there. I would have thought a heading
with no UNITS property would not be included. It is also strange that
the results block did not go beneath this source block, but in the first
results block from the last example. 

below this are the headings that are tagged and with properties. 

Both of those behaviors seem wrong to me. the point does not move in org
7.9.3f, but it does with 8.2.5g. the nil heading shows up in both.


So my questions are:
1. is it a new bug that point moves in 8.2.5g?
2. should the headings with no properties be counted as matches?

Thanks.



** 09-105							  :chemistry:
   :PROPERTIES:
   :UNITS:    9
   :SEMESTER: 1
   :END:
** 09-106							  :chemistry:
   :PROPERTIES:
   :UNITS:    9
   :SEMESTER: 2
   :END:
** 33-105							    :physics:
   :PROPERTIES:
   :UNITS:    12
   :SEMESTER: 1
   :END:
** 33-106							    :physics:
   :PROPERTIES:
   :UNITS:    12
   :SEMESTER: 3
   :END:
** 21-120 							       :math:
   :PROPERTIES:
   :UNITS:    9
   :SEMESTER: 1
   :END:
** 21-122							       :math:
   :PROPERTIES:
   :UNITS:    9
   :SEMESTER: 2
   :END:
** 21-259							       :math:
   :PROPERTIES:
   :UNITS:    9
   :SEMESTER: 3
   :END:
** 03-232							    :biology:
   :PROPERTIES:
   :UNITS:    9
   :SEMESTER: 5
   :END:
** 06-100							:engineering:
   :PROPERTIES:
   :UNITS:    12
   :SEMESTER: 1
   :END:

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: bugs in property searches?
  2014-01-29  2:00 bugs in property searches? John Kitchin
@ 2014-01-29  5:05 ` Nick Dokos
  2014-01-31 12:33   ` Bastien
  0 siblings, 1 reply; 3+ messages in thread
From: Nick Dokos @ 2014-01-29  5:05 UTC (permalink / raw)
  To: emacs-orgmode

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> 1. the point moves in org-map-entries, and I thought it would not since
> the documentation says the function is wrapped in save-excursion. This
> lead to the results going in the wrong place. 
>

I can duplicate this, but I'm not sure whether it's a bug or not. The
doc says that org-map-entries calls FUNC within a save-excursion, not
that org-map-entries itself is wrapped. The code does

	  (cond ((eq scope 'tree)
		 (org-back-to-heading t)
		 (org-narrow-to-subtree)
		 (setq scope nil))
                 ...)

and org-back-to-heading moves point. You can certainly wrap the calls to
org-map-entries within save-excursion and that would work around the
problem. Whether org-map-entries should do that internally, I don't
know. The fact that 7.9.3f does not move point might indicate that
this is indeed a bug.

[Later...]
OK, I played the git blame game and found commit 3ec38f5c:

,----
| commit 3ec38f5c064c3270f54876ba33c5ca1097b46853
| Author: Bastien Guerry <bzg@altern.org>
| Date:   Thu Mar 14 14:40:00 2013 +0100
| 
|     org.el (org-map-entries): Use `save-window-excursion'
|     
|     * org.el (org-map-entries): Use `save-window-excursion'.
| 
| diff --git a/lisp/org.el b/lisp/org.el
| index 66c79f5..52ae163 100644
| --- a/lisp/org.el
| +++ b/lisp/org.el
| @@ -14638,7 +14638,7 @@ a *different* entry, you cannot use these techniques."
|         ((eq match nil) (setq matcher t))
|         (t (setq matcher (if match (cdr (org-make-tags-matcher match)) t))))
|  
| -      (save-excursion
| +      (save-window-excursion
|  	(save-restriction
|  	  (cond ((eq scope 'tree)
|  		 (org-back-to-heading t)
`----

If I change the save-window-excursion back to a save-excursion,
org-map-entries doe not move point. So I guess the ball is in
Bastien's court: why was the save-excursion changed to a
save-window-excursion? Should the whole thing be wrapped in
a save-excursion as well?

> 2. In using a PROPERTY search, headings that did not have the property
> got "mapped".

I can duplicate this too but haven't dug any further.

-- 
Nick

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: bugs in property searches?
  2014-01-29  5:05 ` Nick Dokos
@ 2014-01-31 12:33   ` Bastien
  0 siblings, 0 replies; 3+ messages in thread
From: Bastien @ 2014-01-31 12:33 UTC (permalink / raw)
  To: Nick Dokos; +Cc: emacs-orgmode

Nick Dokos <ndokos@gmail.com> writes:

> OK, I played the git blame game and found commit 3ec38f5c:

I reverted this commit, so this particular bug is fixed*.

Thanks John and Nick,

* I could not remember why I used `save-window-excursion' here.
  I should have documented this in the commit message.  If anyone
  finds out what this was supposed to fix, please let us know.
  But `save-window-excursion' is rarely a good choice, so I think
  we're good like this.

-- 
 Bastien

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-01-31 12:34 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-29  2:00 bugs in property searches? John Kitchin
2014-01-29  5:05 ` Nick Dokos
2014-01-31 12:33   ` Bastien

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).