Re: [BUG] org-cancel-repeater fails depending on position of repeater [9.6.15 (release_9.6.15 @ /opt/homebrew/Cellar/emacs-plus@29/29.4/share/emacs/29.4/lisp/org/)]

[Ihor Radchenko <yantar92@posteo.net>]

solodov@gmail.com writes:

> Minimal test file:
>
> * test
> DEADLINE: <2024-08-02 Fri> SCHEDULED: <2024-07-29 Mon +1d>
>
> After M-x org-cancel-repeater, repeater is still there:
>
> * test
> DEADLINE: <2024-08-02 Fri> SCHEDULED: <2024-07-29 Mon +1d>

Confirmed.

That's true, but I am not sure if it is a bug or just an inaccuracy in
the documentation. The accurate documentation of what
`org-cancel-repeater' does is:

   Cancel a repeater in the first active timestamp in the heading by setting
   its numeric value to zero.
   If there is no repeater in the first timestamp, do nothing.

So, it just removes a repeater in the first timestamp.

On the other hand, looking into git history, I see that the reason why
this function was originally introduced (in 1eb03c8c87) is to prevent
`org-todo' from switching an item marked DONE back to TODO when there
are _any_ (`org-get-repeat') repeaters inside heading. So, it will
follow the original intention to change the function to nullify _all_
the repeaters, not just the one in the first timestamp.

What I am leaning to is to change `org-cancel-repeater' to work on all
the _active_ timestamps inside the heading and introduce an optional
prefix argument to only change first timestamp with non-zero repeater.
WDYT?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>