on Sun Oct 02 2011, Nicolas Goaziou <n.goaziou-AT-gmail.com> wrote: > Dave Abrahams <d...@boostpro.com> writes: > >> I was using checkboxes for a group of subtasks, and was surprised when >> the following (which I lifted from the manual) wasn't causing the parent >> item to be marked DONE upon checking the last box. >> >> (defun dwa/org-summary-todo (n-done n-not-done) >> "Switch entry to DONE when all subentries are done, to TODO otherwise." >> (let (org-log-done org-log-states) ; turn off logging >> (org-todo (if (= n-not-done 0) "DONE" "TODO")))) >> (add-hook 'org-after-todo-statistics-hook 'dwa/org-summary-todo) >> >> So I set some debugger breakpoints and realized that code wasn't even >> getting called. There's a completely separate wad of code in org-list >> that handles checkbox statistics. So naturally, there's a hook, which I >> added my TODO->DONE function to: >> >> (add-hook 'org-checkbox-statistics-hook 'dwa/org-summary-todo) >> >> But `org-checkbox-statistics-hook' is a list of nullary functions, so of >> course this broke since my function expects N-DONE and N-NOT-DONE. I >> looked around for an easy way to determine N-DONE and N-NOT-DONE but it >> doesn't seem to exist; it's buried in the logic of >> org-update-checkbox-count... I think. What I need is a hook that acts >> like org-after-todo-statistics-hook, but for checkboxes. > > You just have to search for "[ ]" or "[-]" in the current section. If > there is none, and there is at least one "[X]", you can mark your task > as done.
Silly me; I was looking for a programmatic interface that would handle things at a level of abstraction above pattern matching in text. But given the number of similar-looking regexps I see scattered through the Org code I'm guessing that's just not the way things are done. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
