Hello Carsten,
thanks for your reply.
Hi Daniel,
yes, this could be seen as a bug. However, the implementation
does not work by scanning the entire buffer and marking tasks
that should be blocked. Rather, it goes to each task and then
scans around to see locally what the dependencies are.
In this case it looks only at the parent, not at the
grand parent.
Wouldn't it be enough to check whether the parent is blocked.
Wouldn't that generate a blocking-chain?
However, the todo
dependencies are simple hook functions, and an interested
programmer could relatively easily extend them, I believe.
I've tried to write a custom org-blocker-hook but it doesn't work,
unfortunately.
Can you (or someone else) tell me please what's wrong with my code?
(defun org-block-todo-with-blocked-parent (change-plist)
;; check whether we are in a endless loop:
(if (plist-get change-plist :org-block-todo-with-blocked-parent)
;; We are in a endless loop: don't block (return t)
t
;; We are not in a endless loop: go to the parent heading
(save-excursion
(org-back-to-heading t)
(ignore-errors (org-up-heading-all 1))
;; generate a fake change-plist with a flag to indicate a
endless loop
(setq fake-change-plist
(list
:type 'todo-state-change
:from "DONE"
:to "TODO"
:position 0
:org-block-todo-with-blocked-parent t))
;; check whether the parent heading should be blocked and return
the result
(save-match-data
(run-hook-with-args-until-failure 'org-blocker-hook fake-
change-plist)))))
(add-hook 'org-blocker-hook 'org-block-todo-with-blocked-parent)
I don't expect to change this because it would make the
mechanism a lot more complex and slower.
I think it's essential to provide this eventuality. For example
this tree:
* organize party
:PROPERTIES:
:ORDERED: t
:END:
** TODO send invitations
*** TODO send invitation to Paul
*** TODO send invitation to Nicole
*** ect.
** TODO buy meals and drinks
:PROPERTIES:
:ORDERED: t
:END:
*** TODO write shopping list
*** TODO get money from my bank account
*** TODO buy food
*** TODO buy drinks
with this tree, only "send invitation to Paul" and "send invitation
to Nicole"
should be on my agenda. But "write shopping list" is also an my agenda
list (although it shouldn't: I can't write a shopping list if I
don't know how
many people will come to my party).
best regards,
Daniel
- Carsten
On Mar 24, 2009, at 8:13 PM, Daniel Hochheimer wrote:
Hello,
first of all, please excuse my poorly english.
It seems there is a bug in the handling of simple dependencies.
I think an example tree is the best solution, to show you the bug:
* Projects
#+CATEGORY: Projects
*** TODO foo bar project
:PROPERTIES:
:ORDERED: t
:END:
***** TODO foo subproject :FooSubproject:
******* TODO Task 1
***** TODO bar subproject :BarSubproject:
******* TODO Task 1
This is in my .emacs file:
(setq org-enforce-todo-dependencies t)
(setq org-agenda-dim-blocked-tasks 'invisible)
(setq org-odd-levels-only t)
the expected global todo agenda view imho is:
Projects: Task 1 :FooSubproject:
but actual it is unfortunately:
Projects: Task 1 :FooSubproject:
Projects: Task 1 :BarSubproject:
Imho "Task 1" from "bar subproject" should not be visible,
because "bar subproject " is blocked because of the
ORDERED property (therefore it's childs should be blocked, too)
Is it easy / possible to fix this bug? My whole GTD system is
heavily based on such project / subproject-Constructs. But with
this bug my global todo agenda view is unfortunately "polluted"
a little bit with tasks from projects that shouldn't be active.
Best regards,
Daniel
PS: many thanks to the developer of this great emacs mode, I really
enjoy org-mode. I started using emacs only because of the great
abilities of org-mode.
_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode