emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: John Kitchin <jkitchin@andrew.cmu.edu>
To: emacs-orgmode@gnu.org
Subject: bugs in property searches?
Date: Tue, 28 Jan 2014 21:00:22 -0500	[thread overview]
Message-ID: <87wqhjv96x.fsf@andrew.cmu.edu> (raw)

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:

             reply	other threads:[~2014-01-29  2:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-29  2:00 John Kitchin [this message]
2014-01-29  5:05 ` bugs in property searches? Nick Dokos
2014-01-31 12:33   ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wqhjv96x.fsf@andrew.cmu.edu \
    --to=jkitchin@andrew.cmu.edu \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).