Re: please read: bug when marking tasks done

[Samuel Wales <samologist@gmail.com>]

some possibly obvious observations:

nobody will want repeating inactive to be changed by org for the bug
case.  those are sacrosanct in that sense.

but if the variable solution is chosen as the sole solution, setting
it to allow changed inactive repeaters will make logbooks no longer
reliable.  i don't think anybody will want that.

"inactive" means "don't show in agenda unless
org-agenda-include-inactive-timestamps is non-nil".  not "sacrosanct".

while i have no use for inactive repeaters, the feature imo should not
be reverted.  it's a good idea.  imagine saying "the next phase of the
project will be on ...".

for the emphasis solution, not everybody wants the verbatim or code
face in the buffer [can be distracting] or on export ["why that
particular string?"].  verbatim is not always set to default.

some might want to have changed repeating inactive without triggering
the bug and also without using the special faces.

inactive repeaters can exist if you have active repeater events [bare
ts or ranges] and decide to "comment them out" by making them inactive
using shift down on the < or >.  some probably do this.

yet they will not want them changed inadvertently if they set the
variable to non-nil and aren't thinking about that.  surprise.

commented repeater cookies does not have any of the above drawbacks.
it might require a 3rd party tool to update its re if that tool uses
repeaters.  this is not unprecedented.  the inactive repeater feature
might already require a 3rd party tool to update its re.

so upon reflection i think i'd go for commentable repeater cookies.
it has a bonus too: whenever you turn off a repeater, it can be
annoying that it zeroes out the interval.  commenting would fix that.

perhaps there is a better, unmentioned solution?