[-- Attachment #1: Type: text/plain, Size: 553 bytes --] I've been wanting a simple method for managing dependent tasks for some time now, and only now did it occur to me that I could just implement a much simpler method using your current blocking mechanism. The attached file, confusingly named org-depends.el, implements the following scheme: 1. Any TODO which has incomplete child TODOs is blocked. 2. If a parent TODO has the ORDERED property, it's children must be completed in order. Undone siblings block later siblings. 3. Blocked items are greyed out in the agenda list. John [-- Attachment #2: org-depends.el --] [-- Type: application/octet-stream, Size: 4353 bytes --] ;;; org-depends.el --- Hierarchical TODO dependencies for Org-mode ;; Copyright (C) 2008 Free Software Foundation, Inc. ;; ;; Author: John Wiegley <johnw at newartisans dot com> ;; Keywords: outlines, hypermedia, calendar, wp ;; Homepage: http://www.newartisans.com/ ;; Version: 0.01 ;; ;; This file is not part of GNU Emacs. ;; ;; This file is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 3, or (at your option) ;; any later version. ;; GNU Emacs is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with GNU Emacs; see the file COPYING. If not, write to the ;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, ;; Boston, MA 02110-1301, USA. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;;; Commentary: ;; (require 'org) (defun org-depends-block-todo (change-plist) "Block turning an entry into a TODO. This checks whether the current task should be blocked from state changes. Such blocking occurs when: 1. The task has children which are not all in a completed state. 2. A task has a parent with the property :ORDERED:, and there are siblings prior to the current task with incomplete status." (catch 'dont-block ;; If this task has children, and any are undone, it's blocked (save-excursion (outline-back-to-heading) (let ((this-level (funcall outline-level))) (outline-next-heading) (let ((child-level (funcall outline-level))) (while (and (not (eobp)) (> child-level this-level)) ;; this todo has children, check whether they are all ;; completed (if (and (not (org-entry-is-done-p)) (org-entry-is-todo-p)) (throw 'dont-block nil)) (outline-next-heading) (setq child-level (funcall outline-level)))))) ;; Otherwise, if the task's parent has the :ORDERED: property, and ;; any previous siblings are undone, it's blocked (save-excursion (outline-back-to-heading) (when (save-excursion (outline-up-heading 1) (org-entry-get (point) "ORDERED")) (let* ((this-level (funcall outline-level)) (current-level this-level)) (while (and (not (bobp)) (= current-level this-level)) (outline-previous-heading) (setq current-level (funcall outline-level)) (if (= current-level this-level) ;; this todo has children, check whether they are all ;; completed (if (and (not (org-entry-is-done-p)) (org-entry-is-todo-p)) (throw 'dont-block nil))))))) t)) ; don't block (add-hook 'org-blocker-hook 'org-depends-block-todo) (defface org-depends-dimmed-todo-face '((((background light)) (:foreground "grey50")) (((background dark)) (:foreground "grey50"))) "Face used to hide leading stars in headlines. The foreground color of this face should be equal to the background color of the frame." :group 'org-depends) (defun org-depends-dim-blocked-todos () "Dim currently blocked TODO's in the agenda display." (interactive) (mapc (lambda (o) (if (eq (org-overlay-get o 'org-type) 'org-blocked-todo) (org-delete-overlay o))) (org-overlays-in (point-min) (point-max))) (save-excursion (let ((inhibit-read-only t) b e p ov h l) (goto-char (point-min)) (while (let ((pos (next-single-property-change (point) 'todo-state))) (and pos (goto-char (1+ pos)))) (let ((marker (get-text-property (point) 'org-hd-marker))) (when (and marker (not (with-current-buffer (marker-buffer marker) (save-excursion (goto-char marker) (org-depends-block-todo (list :type 'todo-state-change :position marker :from "TODO" :to "DONE")))))) (setq b (point) e (point-at-eol) ov (org-make-overlay b e)) (org-overlay-put ov 'face 'org-depends-dimmed-todo-face) (org-overlay-put ov 'org-type 'org-blocked-todo))))))) (add-hook 'org-finalize-agenda-hook 'org-depends-dim-blocked-todos) (provide 'org-depends) ;;; org-depends.el ends here [-- Attachment #3: Type: text/plain, Size: 1 bytes --] [-- Attachment #4: Type: text/plain, Size: 204 bytes --] _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
On Mon, Jan 26, 2009 at 05:16:17PM -0400, John Wiegley wrote:
> I've been wanting a simple method for managing dependent tasks for some
> time now, and only now did it occur to me that I could just implement a
> much simpler method using your current blocking mechanism.
>
> The attached file, confusingly named org-depends.el, implements the
> following scheme:
>
> [ ... ]
This is very cool and I'm immediately in love with it! I'll let you
know if I have any problems, but it seems like it just works. Neat.
--
Oliver Charles / aCiD2
Oliver Charles <oliver.g.charles@googlemail.com> writes:
> On Mon, Jan 26, 2009 at 05:16:17PM -0400, John Wiegley wrote:
>> I've been wanting a simple method for managing dependent tasks for some
>> time now, and only now did it occur to me that I could just implement a
>> much simpler method using your current blocking mechanism.
>>
>> The attached file, confusingly named org-depends.el, implements the
>> following scheme:
>>
>> [ ... ]
>
> This is very cool and I'm immediately in love with it! I'll let you
> know if I have any problems, but it seems like it just works. Neat.
Any chance of putting this into the org codebase (if not as one of the
core modules, then as a contrib module)?
Jesse
--
Jesse Alama (alama@stanford.edu)
On Jan 27, 2009, at 2:18 AM, Jesse Alama wrote: > Oliver Charles <oliver.g.charles@googlemail.com> writes: > >> On Mon, Jan 26, 2009 at 05:16:17PM -0400, John Wiegley wrote: >>> I've been wanting a simple method for managing dependent tasks for >>> some >>> time now, and only now did it occur to me that I could just >>> implement a >>> much simpler method using your current blocking mechanism. >>> >>> The attached file, confusingly named org-depends.el, implements the >>> following scheme: >>> >>> [ ... ] >> >> This is very cool and I'm immediately in love with it! I'll let you >> know if I have any problems, but it seems like it just works. Neat. > > Any chance of putting this into the org codebase (if not as one of the > core modules, then as a contrib module)? Anything John sends my way gets a pretty good chance at that :-) - Carsten > > > Jesse > > -- > Jesse Alama (alama@stanford.edu) > > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 300 bytes --] On Jan 26, 2009, at 5:16 PM, John Wiegley wrote: > The attached file, confusingly named org-depends.el, implements the > following scheme: I found a bug which would cause a Lisp error when trying to change the state of top-level TODO items. The attached version (now 1.0) fixes this. John [-- Attachment #2: org-depends.el --] [-- Type: application/octet-stream, Size: 4365 bytes --] ;;; org-depends.el --- Hierarchical TODO dependencies for Org-mode ;; Copyright (C) 2008 Free Software Foundation, Inc. ;; ;; Author: John Wiegley <johnw at newartisans dot com> ;; Keywords: outlines, hypermedia, calendar, wp ;; Homepage: http://www.newartisans.com/ ;; Version: 1.0 ;; ;; This file is not part of GNU Emacs. ;; ;; This file is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 3, or (at your option) ;; any later version. ;; GNU Emacs is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with GNU Emacs; see the file COPYING. If not, write to the ;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, ;; Boston, MA 02110-1301, USA. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;;; Commentary: ;; (require 'org) (defun org-depends-block-todo (change-plist) "Block turning an entry into a TODO. This checks whether the current task should be blocked from state changes. Such blocking occurs when: 1. The task has children which are not all in a completed state. 2. A task has a parent with the property :ORDERED:, and there are siblings prior to the current task with incomplete status." (catch 'dont-block ;; If this task has children, and any are undone, it's blocked (save-excursion (outline-back-to-heading) (let ((this-level (funcall outline-level))) (outline-next-heading) (let ((child-level (funcall outline-level))) (while (and (not (eobp)) (> child-level this-level)) ;; this todo has children, check whether they are all ;; completed (if (and (not (org-entry-is-done-p)) (org-entry-is-todo-p)) (throw 'dont-block nil)) (outline-next-heading) (setq child-level (funcall outline-level)))))) ;; Otherwise, if the task's parent has the :ORDERED: property, and ;; any previous siblings are undone, it's blocked (save-excursion (outline-back-to-heading) (when (save-excursion (ignore-errors (outline-up-heading 1) (org-entry-get (point) "ORDERED"))) (let* ((this-level (funcall outline-level)) (current-level this-level)) (while (and (not (bobp)) (= current-level this-level)) (outline-previous-heading) (setq current-level (funcall outline-level)) (if (= current-level this-level) ;; this todo has children, check whether they are all ;; completed (if (and (not (org-entry-is-done-p)) (org-entry-is-todo-p)) (throw 'dont-block nil))))))) t)) ; don't block (add-hook 'org-blocker-hook 'org-depends-block-todo) (defface org-depends-dimmed-todo-face '((((background light)) (:foreground "grey50")) (((background dark)) (:foreground "grey50"))) "Face used to hide leading stars in headlines. The foreground color of this face should be equal to the background color of the frame." :group 'org-depends) (defun org-depends-dim-blocked-todos () "Dim currently blocked TODO's in the agenda display." (interactive) (mapc (lambda (o) (if (eq (org-overlay-get o 'org-type) 'org-blocked-todo) (org-delete-overlay o))) (org-overlays-in (point-min) (point-max))) (save-excursion (let ((inhibit-read-only t) b e p ov h l) (goto-char (point-min)) (while (let ((pos (next-single-property-change (point) 'todo-state))) (and pos (goto-char (1+ pos)))) (let ((marker (get-text-property (point) 'org-hd-marker))) (when (and marker (not (with-current-buffer (marker-buffer marker) (save-excursion (goto-char marker) (org-depends-block-todo (list :type 'todo-state-change :position marker :from "TODO" :to "DONE")))))) (setq b (point) e (point-at-eol) ov (org-make-overlay b e)) (org-overlay-put ov 'face 'org-depends-dimmed-todo-face) (org-overlay-put ov 'org-type 'org-blocked-todo))))))) (add-hook 'org-finalize-agenda-hook 'org-depends-dim-blocked-todos) (provide 'org-depends) ;;; org-depends.el ends here [-- Attachment #3: Type: text/plain, Size: 2 bytes --] [-- Attachment #4: Type: text/plain, Size: 204 bytes --] _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Do you think it makes sense to integrate this code into org-depend.el?
- Carsten
On Jan 26, 2009, at 10:16 PM, John Wiegley wrote:
> I've been wanting a simple method for managing dependent tasks for
> some time now, and only now did it occur to me that I could just
> implement a much simpler method using your current blocking mechanism.
>
> The attached file, confusingly named org-depends.el, implements the
> following scheme:
>
> 1. Any TODO which has incomplete child TODOs is blocked.
>
> 2. If a parent TODO has the ORDERED property, it's children must be
> completed in order. Undone siblings block later siblings.
>
> 3. Blocked items are greyed out in the agenda list.
>
> John
>
> <org-depends.el>
On Jan 27, 2009, at 2:47 AM, Carsten Dominik wrote:
> Do you think it makes sense to integrate this code into org-depend.el?
Actually, I don't, since it's a completely different approach. org-
depend.el as it stands now is based on a programmatic methodology,
which more complex blocking schemes could be built on top of.
I think this module represents something much simpler, which should be
toggled by a single global boolean to indicate "on" or "off". My
preference would be to see it mainlined, if that meets with your
approval, Carsten.
John
Hi John,
I realize now that you do not make use of the code in
org-depend.el at all, which is what I thought at first.
Two options:
- I can add the file, but then under a different name - org-depend
and org-depends are not different in the first 8 characters.
- I can move the code to org-agenda.el and create a variable to
turn this behavior on and off.
- Carsten
On Jan 27, 2009, at 8:31 AM, John Wiegley wrote:
> On Jan 27, 2009, at 2:47 AM, Carsten Dominik wrote:
>
>> Do you think it makes sense to integrate this code into org-
>> depend.el?
>
> Actually, I don't, since it's a completely different approach. org-
> depend.el as it stands now is based on a programmatic methodology,
> which more complex blocking schemes could be built on top of.
>
> I think this module represents something much simpler, which should
> be toggled by a single global boolean to indicate "on" or "off". My
> preference would be to see it mainlined, if that meets with your
> approval, Carsten.
>
> John
>
On Mon, 26 Jan 2009 17:16:17 -0400
John Wiegley <johnw@newartisans.com> wrote:
> I've been wanting a simple method for managing dependent tasks for
> some time now, and only now did it occur to me that I could just
> implement a much simpler method using your current blocking mechanism.
>
> The attached file, confusingly named org-depends.el, implements the
> following scheme:
>
> 1. Any TODO which has incomplete child TODOs is blocked.
>
> 2. If a parent TODO has the ORDERED property, it's children must be
> completed in order. Undone siblings block later siblings.
>
> 3. Blocked items are greyed out in the agenda list.
>
> John
>
This sounds like a sensible approach that would cover most my needs for
dependencies between TODOs
--
Mike
John Wiegley schrieb: > I've been wanting a simple method for managing dependent tasks for some > time now, and only now did it occur to me that I could just implement a > much simpler method using your current blocking mechanism. > > The attached file, confusingly named org-depends.el, implements the > following scheme: > > 1. Any TODO which has incomplete child TODOs is blocked. > > 2. If a parent TODO has the ORDERED property, it's children must be > completed in order. Undone siblings block later siblings. > > 3. Blocked items are greyed out in the agenda list. > > John > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode John Wiegley schrieb: > I've been wanting a simple method for managing dependent tasks for some > time now, and only now did it occur to me that I could just implement a > much simpler method using your current blocking mechanism. > > The attached file, confusingly named org-depends.el, implements the > following scheme: > > 1. Any TODO which has incomplete child TODOs is blocked. > > 2. If a parent TODO has the ORDERED property, it's children must be > completed in order. Undone siblings block later siblings. > > 3. Blocked items are greyed out in the agenda list. > > John > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode Excellent feature! Thanks a lot! Unfortunately most of the times I do use this approach: * TODO something [0/3] - [ ] part 1 - [ ] part 2 - [ ] part 3 I would like to get the blocking behavior for the checklist also. "Any TODO which has incomplete child items is blocked." Even better would additionally be something like: "Any TODO having at least one item checked is allows the TODO to be set to the next possible state, for me it would be 'INWORK'." Any chance to get at least the blocker feature - the order feature would at least for me be lower priority? Rainer
Hi Rainer, On Jan 30, 2009, at 4:02 PM, Rainer Stengele wrote: > John Wiegley schrieb: >> I've been wanting a simple method for managing dependent tasks for >> some >> time now, and only now did it occur to me that I could just >> implement a >> much simpler method using your current blocking mechanism. >> >> The attached file, confusingly named org-depends.el, implements the >> following scheme: >> >> 1. Any TODO which has incomplete child TODOs is blocked. >> >> 2. If a parent TODO has the ORDERED property, it's children must be >> completed in order. Undone siblings block later siblings. >> >> 3. Blocked items are greyed out in the agenda list. >> >> John >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Emacs-orgmode mailing list >> Remember: use `Reply All' to send replies to the list. >> Emacs-orgmode@gnu.org >> http://lists.gnu.org/mailman/listinfo/emacs-orgmode > > John Wiegley schrieb: >> I've been wanting a simple method for managing dependent tasks for >> some >> time now, and only now did it occur to me that I could just >> implement a >> much simpler method using your current blocking mechanism. >> >> The attached file, confusingly named org-depends.el, implements the >> following scheme: >> >> 1. Any TODO which has incomplete child TODOs is blocked. >> >> 2. If a parent TODO has the ORDERED property, it's children must be >> completed in order. Undone siblings block later siblings. >> >> 3. Blocked items are greyed out in the agenda list. >> >> John >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Emacs-orgmode mailing list >> Remember: use `Reply All' to send replies to the list. >> Emacs-orgmode@gnu.org >> http://lists.gnu.org/mailman/listinfo/emacs-orgmode > > Excellent feature! Thanks a lot! > Unfortunately most of the times I do use this approach: > > * TODO something [0/3] > - [ ] part 1 > - [ ] part 2 > - [ ] part 3 > > I would like to get the blocking behavior for the checklist also. > > "Any TODO which has incomplete child items is blocked." Yes, this is an obvious extension, and I was implementing this already. It is now present in the git repo, dependent on the variable org-enforce-todo-checkbox-dependencies. > Even better would additionally be something like: > > "Any TODO having at least one item checked is allows the TODO to be > set to the > next possible state, for me it would be 'INWORK'." I think is is too special. You may want to switch such an entry to INWORK even before the first checkbox can be checked off. Or you may want to switch to WAITING because you are waiting for an email that will allow you to check off the first item... So my feeling is that switching from one not-done state to another not-done state should not be blocked at all. In fact, I feel the same for the straight TODO dependencies. I have now adapted John's mechanism in the following way: - You are free to change between the different non-done states - Entries that cannot be switched to DONE will be greyed in the agenda, but you can still use the agenda to switch them between not-done states. - If you call `C-c C-t' (or `t' in the agenda) with a tripple C-u prefix, any blocking will be circumvented for the upcoming state change. This is good if you want to cancel such a tree, before all subitems are done. I think this is good, and I hope that John agrees. > Any chance to get at least the blocker feature - the order feature > would at > least for me be lower priority? No plans to make an ORDER feature for checkboxes. Checkboxes should be light. Thanks for your input! - Carsten > > Rainer >
On Jan 30, 2009, at 1:37 PM, Carsten Dominik wrote:
> So my feeling is that switching from one not-done state to
> another not-done state should not be blocked at all.
> In fact, I feel the same for the straight TODO dependencies.
>
> I have now adapted John's mechanism in the following way:
>
> - You are free to change between the different non-done states
>
> - Entries that cannot be switched to DONE will be greyed in
> the agenda, but you can still use the agenda to switch them
> between not-done states.
>
> - If you call `C-c C-t' (or `t' in the agenda) with a
> tripple C-u prefix, any blocking will be circumvented
> for the upcoming state change. This is good if you
> want to cancel such a tree, before all subitems are done.
>
> I think this is good, and I hope that John agrees.
Very much so, that's a great extension. I use checkboxes like Rainer
does constantly, for "lightweight dependent" tasks. I'll make use of
this extension a great deal.
John