solo...@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>
