Bob Wilson writes: > I use the org-checklist add-on so that marking the task as complete > resets the checkboxes to empty. But I noticed that every time I do so, > it resets the statistics cookies everywhere else in the org file! And > by reset, I mean it replaces things like [5/7] with [0/0]. I have to > do C-u C-c # (org-update-statistics-cookies ALL) to fix it.
[ Rearranging things to lead with your complete example first... ] > * Task A [1/2] > ** DONE Subtask A.1 > CLOSED: [2020-11-12 Thu 08:47] > ** TODO Subtask A.2 > * TODO Daily Wind-Down > SCHEDULED: <2020-11-12 Thu 17:00 +1d> > :PROPERTIES: > :RESET_CHECK_BOXES: t > :END: > - [ ] Respond to emails > - [ ] Pat myself on the back > > Marking the Daily Wind-Down as complete resets the buffer so it looks like: > * Task A [0/0] > ** DONE Subtask A.1 > CLOSED: [2020-11-12 Thu 08:47] > ** TODO Subtask A.2 > * TODO Daily Wind-Down > SCHEDULED: <2020-11-13 Fri 17:00 +1d> > :PROPERTIES: > :RESET_CHECK_BOXES: t > :LAST_REPEAT: [2020-11-12 Thu 08:47] > :END: > - [ ] Respond to emails > - [ ] Pat myself on the back > > The first line shows the problem: the statistics cookies have updated > to [0/0]. Thanks. I can trigger that as well. So, with the example from <https://orgmode.org/list/87fwn4bhcy....@gmail.com/>, the issue is that, without specifying `all', the _checkbox_ statistics for sibling subheadings do not get updated, just the last one. In contrast, the problem here looks to be that org-update-checkbox-count will result in _todo_ statistics being set to zero, and it doesn't take care of refreshing them. This problem goes away with the higher-level org-update-statistics-cookies because it calls (org-update-checkbox-count 'all) but _then_ follows up with a call to (org-map-entries 'org-update-parent-todo-statistics). > Just for completeness, I will write out my thoughts (and you’ll soon > see just how little I know of elisp — I apologize!). Here is the > org-reset-checkbox-state-subtree as of 9.4: > > (defun org-reset-checkbox-state-subtree () [...] > (org-update-checkbox-count-maybe 'all))))) > > In the last line, it calls org-update-checkbox-count-maybe with ‘all > argument. I don’t full understand the single quote part. My > understanding is that it tells lisp not to evaluate the value (which > is good, because there is no all variable defined at this scope). Yes, that's right. (info "(elisp)Quoting") has more details. > My only idea here is that it’s a way of saying, “by the time you > actually need this value, I’ll have told you what it is”. But what is > relevant is that I don’t think ‘all is nil; it’s some kind of > placeholder, so it effectively gets evaluated as true. Or so it seems > to me. > > org-update-checkbox-count-maybe passes this placeholder unmodified to > org-update-checkbox-count which does all the heavy lifting. But > nowhere is the all argument ever modified, it continues to be that > non-nil placeholder, which seems to get evaluated as true. It’s not > clear to me why this placeholder would get passed to the function if > it is never set to anything else. But again, I don’t fully understand > the single quote syntax. In this particular case, org-update-checkbox-count doesn't check for a _specific_ non-nil value, so indeed the only thing that is important is that the value of org-update-checkbox-count's ALL ends up non-nil. t (no need to quote), or any number of things aside from nil, could be passed instead. Using "'all" rather than "t" here is just making things a bit more readable by hinting what the parameter/effect is. > The org-update-checkbox-count is quite complicated (from my > elisp-neophyte perspective), so it is not clear to me why it resets > the statistics cookies to [0/0], but whatever it does, it does it in > the entire file. > > The “fix” that I made was on the first and last lines of the function: > > (defun org-reset-checkbox-state-subtree (&optional all) > ... > (org-update-checkbox-count-maybe all))))) > > where you can see all I did was remove the single quote from all, and > added all as an optional parameter. Now I feel like this was the wrong > fix, but it does solve my problem! Right, it's problematic because it'd bring back the previous issue with sibling checkbox statistics not being updated. > Maybe the real problem had nothing to do with the entire buffer part, > and was more about why the statistics cookies get updated to [0/0]. That's my current thinking, but I haven't taken a closer look at org-update-checkbox-count yet.
