Hi Bastien,
Thanks for pointing out `org-provide-todo-statistics'. I was not
familiar with this option or the different forms its value can take.
Of the proposed names, I would still lean towards the positive
`org-todo-recursive-statistics' and `org-checkbox-recursive-statistics'.
Although “non-recursive” would preserve the existing polarity, a setting
such as
(setq org-todo-non-recursive-statistics nil)
requires reasoning through a double negative to understand that
recursive collection is enabled.
The positive form would also have natural default semantics. With nil,
statistics would retain their narrower scope and cover direct children
only. Setting the option to t would explicitly opt into the broader,
recursive scope covering the entire subtree. In other words, enabling
the option would add behavior and expand its scope, which I find easier
to understand than disabling a restriction.
However, I agree that changing the polarity should not require users to
modify their configurations manually. Existing settings should retain
their behavior:
old t -> new nil
old nil -> new t
AFAIK, an ordinary obsolete variable alias cannot perform this conversion.
I considered retaining the old options as obsolete compatibility
variables and using `add-variable-watcher' to keep their values
synchronized with the new options using the opposite polarity. This
could also handle assignments made after Org has been loaded. However,
it appears disproportionately complicated for a variable rename and
potentially fragile, particularly with initialization order, dynamic
bindings, and buffer-local values. I also could not find an existing
precedent for this approach in Org.
Is there an established Emacs or Org mechanism for migrating an
obsolete option when its replacement has the opposite polarity, while
preserving existing user configurations automatically?
If there is no reliable established migration mechanism, I would
instead propose:
- `org-checkbox-direct-children-statistics'
- `org-todo-direct-children-statistics'
These names are positive and explicitly describe the non-nil behavior,
while preserving the current polarity. Ordinary obsolete variable
aliases would therefore be sufficient for backward compatibility.
--
Slawomir Grochowski
