Justin Silverman <jsilv...@gmail.com> writes: js > Org no longer allows the third argument in (file+olp+datetree ...
And Ihor Radchenko <yanta...@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 --
