Bug: org-clone-subtree-with-time-shift throws error [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

Bug: org-clone-subtree-with-time-shift throws error [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

[skaphle]

[-- Attachment #1.1: Type: text/plain, Size: 2543 bytes --]

Summary: using org-clone-subtree-with-time-shift on an entry with the ID property and a timestamp causes an error or does not create different IDs, which worked before 27.1.

Long Description:

I have a calendar file with a lot of entries, but I slimmed it down to a MWE:

=== begin MWE ===
* my appointment with id
  :PROPERTIES:
  :ID:       048c5a49-1aed-45d4-b7a9-34caf4f13266
  :END:
  <2020-11-15 Sun 15:30>
  example text
=== end MWE ===

I create such an entry routinely via a capture template with a timestamp and I add the text, and the ID is created with (add-hook 'org-capture-prepare-finalize-hook 'org-id-get-create). For repeating tasks, 10 weeks ago and before (i.e. before I updated to 27.1), I used to use `M-x org-clone-subtree-with-time-shift <RET> 10 <RET> +1w <RET>` and I got 10 repetitions, each with a separate unique ID.

I tried this now and I get an error "wrong-type-argument stringp nil", with the backtrace described below. If I change the order of the timestamp and the properties drawer in the MWE, I get the date-shifted clones but each with the same ID. In my calendar file with lots of entries, I still get the same error if I change the order, so I suspect that the function is context sensitive.

Anyway to reproduce the error,
1. save the above MWE in an org file
2. open the file with emacs -Q
3. activate debugger with `M-x toggle-debug-on-error <RET>`
4. run `M-x org-clone-subtree-with-time-shift <RET> 10 <RET> +1w <RET>`

The following backtrace is then produced:

=== begin backtrace ===
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("^/tmp_mnt/" nil)
  abbreviate-file-name(nil)
  org-id-add-location("9f1a8e57-e9be-42aa-a113-f8f478cc2a1b" nil)
  org-id-get(1 create)
  org-id-get-create(t)
  org-clone-subtree-with-time-shift(10)
  funcall-interactively(org-clone-subtree-with-time-shift 10)
  call-interactively(org-clone-subtree-with-time-shift record nil)
  command-execute(org-clone-subtree-with-time-shift record)
  execute-extended-command(nil "org-clone-subtree-with-time-shift" "org-clone")
  funcall-interactively(execute-extended-command nil "org-clone-subtree-with-time-shift" "org-clone")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)
=== end backtrace ===

Emacs  : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo version 1.17.3)
 of 2020-08-28
Package: Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)

[-- Attachment #1.2: publickey - skaphle@pm.me - 0x0422F3DC.asc --]
[-- Type: application/pgp-keys, Size: 1770 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 509 bytes --]

Bug: org-clone-subtree-with-time-shift throws error [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

[skaphle]

[-- Attachment #1.1: Type: text/plain, Size: 2543 bytes --]

Summary: using org-clone-subtree-with-time-shift on an entry with the ID property and a timestamp causes an error or does not create different IDs, which worked before 27.1.

Long Description:

I have a calendar file with a lot of entries, but I slimmed it down to a MWE:

=== begin MWE ===
* my appointment with id
  :PROPERTIES:
  :ID:       048c5a49-1aed-45d4-b7a9-34caf4f13266
  :END:
  <2020-11-15 Sun 15:30>
  example text
=== end MWE ===

I create such an entry routinely via a capture template with a timestamp and I add the text, and the ID is created with (add-hook 'org-capture-prepare-finalize-hook 'org-id-get-create). For repeating tasks, 10 weeks ago and before (i.e. before I updated to 27.1), I used to use `M-x org-clone-subtree-with-time-shift <RET> 10 <RET> +1w <RET>` and I got 10 repetitions, each with a separate unique ID.

I tried this now and I get an error "wrong-type-argument stringp nil", with the backtrace described below. If I change the order of the timestamp and the properties drawer in the MWE, I get the date-shifted clones but each with the same ID. In my calendar file with lots of entries, I still get the same error if I change the order, so I suspect that the function is context sensitive.

Anyway to reproduce the error,
1. save the above MWE in an org file
2. open the file with emacs -Q
3. activate debugger with `M-x toggle-debug-on-error <RET>`
4. run `M-x org-clone-subtree-with-time-shift <RET> 10 <RET> +1w <RET>`

The following backtrace is then produced:

=== begin backtrace ===
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("^/tmp_mnt/" nil)
  abbreviate-file-name(nil)
  org-id-add-location("9f1a8e57-e9be-42aa-a113-f8f478cc2a1b" nil)
  org-id-get(1 create)
  org-id-get-create(t)
  org-clone-subtree-with-time-shift(10)
  funcall-interactively(org-clone-subtree-with-time-shift 10)
  call-interactively(org-clone-subtree-with-time-shift record nil)
  command-execute(org-clone-subtree-with-time-shift record)
  execute-extended-command(nil "org-clone-subtree-with-time-shift" "org-clone")
  funcall-interactively(execute-extended-command nil "org-clone-subtree-with-time-shift" "org-clone")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)
=== end backtrace ===

Emacs  : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo version 1.17.3)
 of 2020-08-28
Package: Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 509 bytes --]

Re: Bug: org-clone-subtree-with-time-shift throws error [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

[Kyle Meyer]

skaphle@pm.me writes:

> Summary: using org-clone-subtree-with-time-shift on an entry with the
> ID property and a timestamp causes an error or does not create
> different IDs, which worked before 27.1.
>
> Long Description:
>
> I have a calendar file with a lot of entries, but I slimmed it down to a MWE:
>
> === begin MWE ===
[...]

Thanks for detailed report and nice reproduction steps.

I believe this has already been addressed by c716b7c08 (org-id: Allow
file name to be overridden on ID creation, 2020-04-16), which was
included in the 9.3.7 release.

related thread: https://orgmode.org/list/87a73caayj.fsf@phaktory/T/#u

Re: Bug: org-clone-subtree-with-time-shift throws error [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

[skaphle]

[-- Attachment #1.1: Type: text/plain, Size: 661 bytes --]

Kyle Meyer wrote:
[...]
> Thanks for detailed report and nice reproduction steps.
> 

> I believe this has already been addressed by c716b7c08 (org-id: Allow
> file name to be overridden on ID creation, 2020-04-16), which was
> included in the 9.3.7 release.
> 

> related thread: https://orgmode.org/list/87a73caayj.fsf@phaktory/T/#u
>

Thanks for the reply. I used the version shipped with emacs in the report, and now I installed org 9.4 from the gnu default repository via package-list-packages within emacs and the error indeed goes away. Is that the recommended stable version to use? Should I report bugs against the latest git version only?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 509 bytes --]

Re: Bug: org-clone-subtree-with-time-shift throws error [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

[Kyle Meyer]

skaphle@pm.me writes:

> Thanks for the reply. I used the version shipped with emacs in the
> report, and now I installed org 9.4 from the gnu default repository
> via package-list-packages within emacs and the error indeed goes
> away. Is that the recommended stable version to use?

I suppose it depends largely on the user.  For many, the version of Org
bundled with Emacs will do, and it's not worth the hassle of installing
it from another source.  But, if you've hit into a bug that's fixed in
the latest release or just always want to keep up with the latest
release, then the default ELPA source is a good choice.

There's also Org's ELPA archives, if you instead wanted code based off
of the maint branch.

  https://orgmode.org/elpa.html

> Should I report bugs against the latest git version only?

Reporting a bug against the Org bundled with Emacs is fine.  Many times
this issue is still around, and a fix is applied to the maint branch and
will be included in the next release.  But if it turns out that it's
already fixed, then there's no other action we take on our end.
However, if a reporter is willing to take the time to check the latest
release (or even the maint or master branch) or search the mailing list
archives, that's of course appreciated and helpful.