George Mauer <gma...@gmail.com> writes:
> * Cascading Checkbox Cookie Counts
> I would like checkbox cookies to show the total of all cookies beneath them
> regardless of hierarchy nesting.
> The code for ~org-update-checkbox-count~ is more complex than I expected so
> before spending time digging into this, maybe someone here has a
> tip?
>
> ** This should show 3/5 [1/2]
> - [X] Done
> - [ ] Not Done
> ** Nesting level 1
> - [ ] Not Done
> - [X] Done
> ** Nesting level 2
> *** Nesting level 2.1
> - [X] Done
>
> ** Cookie data recursive doesn't seem to affect this
> My understanding is that there's a cookie data ~<recursive>~ property flag
> you can use. I assumed that's what this was for but it seems to not
> affect things (I've tried both with and without the angle braces, but the
> regex seems to imply braces which is odd)
> *** This should show 3/5 [1/2]
> :PROPERTIES:
> :COOKIE_DATA: <recursive>
> :END:
> - [X] Done
> - [ ] Not Done
> *** Nesting level 1
> - [ ] Not Done
> - [X] Done
> *** Nesting level 2
> **** Nesting level 2.1
> - [X] Done
I think there may be some confusion regarding expected and actual
behaviour. Possibly the manual could be clarified a bit. I did find one
error in the manual where it refers to
org-hierarchical-checkbox-statistics when the variable is actually
called org-checkbox-hierarchical-statistics. I think it is actually the
variable name in the code which is incorrect as there is a
org-hierarchical-todo-statistics - seems somewhat inconsistent. Probably
should rename the variable in the code to be
org-hierarchical-checkbox-statistics to be consistent.
Where I think there is confusion is that when the manual talks about the
hierarchical structure, it is talking about the list item structure e.g.
* This should show 1/2 [1/2]
- [X] Item 1
- [-] Item 2
- [ ] Item 2.1
- [X] Item 2.2
- [X] Item 2.2.1
or
* This should show 3/5 [2/5]
:PROPERTIES:
:COOKIE_DATA: recursive
:END:
- [X] Item 1
- [-] Item 2
- [ ] Item 2.1
- [-] Item 2.2
- [X] Item 2.2.1
if you want a checkbox hierarchy, they can be of different levels, but must
all be within the same list environment. You cannot have checkboxes spread
across different sub trees (heading levels)
While I can see what you are after, I cannot see how the current
implementation could be changed and not result in significant breakage
for others. I also think the code is complex enough that if you also
removed the restriction that the checkbox hierarchy has to be within the
same heading, it would become even more complex and would likely result
in significant performance impact as you would now need to search
multiple heading hierarchies etc.
