Re: [BUG] Invalid capture datetree capture templates (newly introduced) [9.7-pre (release_9.6.18-1145-g10d286 @ /home/jds6696/.emacs.d/straight/build/org/)]

[Tommy Kelly]

Justin Silverman <jsilve24@gmail.com> writes:
js > Org no longer allows the third argument in (file+olp+datetree ...

And Ihor Radchenko <yantar92@posteo.net> replied:
ir > Duplicate of https://list.orgmode.org/878r3xfm90.fsf@localhost/T/#t
ir > Canceled.

The initial problem has certainly been fixed in that the headline(s)
arguments to file+olp+datetree (f+o+d) are now optional as the doc
implies should be the case.
But I don't think the new behavior is fully correct either, and the
problem affects not just the situation where no headline arguments are
given.
It seems to be connected with how the location of the datetree is
chosen in general.

My expectation (going by prior behaviors as well as current
documentation) is that the location is fully specified by the capture
template. For example, suppose you have the following:

A) entry (file+olp+datetree "test-datetree.org")                   ;;
i.e. filename only
B) entry (file+olp+datetree "test-datetree.org" "H1")           ;;
filename plus heading
C) entry (file+olp+datetree "test-datetree.org" "H1 "H2")    ;;
filename plus heading and sub-heading

Then I'd expect A) to use a datetree rooted at the file top level; B)
to use one underneath heading "* H1"; and C) to use one underneath **
H2" (which itself is underneath "* H1").
And in each case I'd expect it to create a new datetree at the
specified location if one didn't already exist.

HOWEVER, it looks like that can break if there is already one or more
datetrees anywhere in the file AT A LEVEL BELOW THAT specified by the
template.
In that case, the position specified by the template is simply
ignored. Instead, the captured item is filed at first occurring
datetree of the above kind.
To be clear, that's even if there is also a pre-existing datetree at
the correct, template-specified location but further down the file.

I tested the situation with all three of the above types available as
capture types, and starting with an empty target file (other than the
two headings "* H1" and "** H2").
I first captured to type A) and I got what I expected: a datetree with
the "2004" root entry being at the file top level. That was positioned
(textually, not hierarchically) beneath the two "H" headings I'd
prepared the file with in the first place.
Then I captured to type C), and also got what I expected; a second
datetree, now with the root being "*** 2004", under "** H2".

But from that point on, all captures, of any of the three types all
went to the one created by that type C) capture -- i.e. to "*** 2004",
under "** H2". under "* H1".
I don't think that's expected/correct behavior.

As to my version of Org: I'm doing all this in my own git copy,
refreshed ("pull"ed?) last night, but I'm still very new to that
approach so this may not be what is usually looked for (and I'd
appreciate the correction if needed), but 'org-version' reports:
- Org mode version 9.7-pre (release_N/A-N/A-ee395b @
/home/tommyk/my/git/org-mode/lisp/)

And if it matters, here's emacs-version:
- GNU Emacs 28.2 (build 2, aarch64-unknown-linux-gnu, X toolkit, cairo
version 1.16.0, Xaw3d scroll bars) of 2023-05-13, modified by Debian

--