[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/)]

[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/)]

[solodov]

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>

Now test with SCHEDULED first:

* test
SCHEDULED: <2024-07-29 Mon +1d> DEADLINE: <2024-08-02 Fri>

After M-x org-cancel-repeater, repeater is correctly cleared:

* test
SCHEDULED: <2024-07-29 Mon +0d> DEADLINE: <2024-08-02 Fri>

Emacs  : GNU Emacs 29.4 (build 1, aarch64-apple-darwin23.5.0, NS
appkit-2487.60 Version 14.5 (Build 23F79))
 of 2024-06-28
Package: Org mode version 9.6.15 (release_9.6.15 @
/opt/homebrew/Cellar/emacs-plus@29/29.4/share/emacs/29.4/lisp/org/)

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]

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>

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/)]

[Peter Solodov]

Changing `org-cancel-repeater' to work on all active timestamps makes
the most sense to me. The reason this came up at all is because org
changes order of timestamps, first timestamp is always the timestamp
that was changed last. If entry is a state where current code can handle
it correctly and then timestamp with repeater is shifted through a
normal user action (updating deadline or scheduled), then canceling with
repeater override is unexpectedly broken.

Ihor Radchenko <yantar92@posteo.net> writes:

> 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>

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]

Peter Solodov <solodov@gmail.com> writes:

> Changing `org-cancel-repeater' to work on all active timestamps makes
> the most sense to me. The reason this came up at all is because org
> changes order of timestamps, first timestamp is always the timestamp
> that was changed last. If entry is a state where current code can handle
> it correctly and then timestamp with repeater is shifted through a
> normal user action (updating deadline or scheduled), then canceling with
> repeater override is unexpectedly broken.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9c98b21460

-- 
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>