Dear Gustav, Thanks for the update. For now, I fixed the problem for me with the following advice:
#+begin_src emacs-lisp (define-advice org-attach-dir (:filter-return (dir) yant/org-attach-use-attach-dir-inheritance -100) "Use :ATTACH_DIR_INHERIT: property." (let ((attach-dir-inherited (and (org-entry-get-with-inheritance "ATTACH_DIR_INHERIT") (not (org-entry-get (point) "ATTACH_DIR_INHERIT" nil)) (org-with-point-at org-entry-property-inherited-from (org-attach-dir))))) (or attach-dir-inherited dir))) #+end_src Regards, Ihor Gustav Wikström <gus...@whil.se> writes: > Hi Ihor, > >> -----Original Message----- >> From: Ihor Radchenko <yanta...@gmail.com> >> Sent: den 27 juli 2019 16:56 >> To: Gustav Wikström <gus...@whil.se>; Nicolas Goaziou >> <m...@nicolasgoaziou.fr> >> Cc: emacs-orgmode@gnu.org >> Subject: Re: [O] [RFC] Link-type for attachments, more attach options > >> I just found that removing ATTACH_DIR_INHERIT broke my current >> configuration. I do not use ATTACH_DIR property - all the attachment >> folders are created using ID. Also, I use ID property to store links to >> entries. Therefore, inheriting ATTACH_DIR does nothing for me and >> inheriting ID always gives the current entry's id value. At the end, I >> cannot make a common attachment directory for the whole subtree, like I >> was able to do with ATTACH_DIR_INHERIT. > > Ah, yes. That is an unfortunate side effect of ID properties having > other use-cases outside of attachments. I thought about that for some > time during the development but didn't get to implement any solution > for it. The way I thought to do it was to create an algorithm that > looks through the outline hierarchy at successively lower hierarchy > for an ID property that has a corresponding attachment folder. If no > folder exist for the ID attribute at the given level, the inherit > functionality would continue to look at a lower level until a folder > was found. I imagined the algorithm to look for both ID and DIR > properties at each level and stop at the first property that had an > existing attachment folder, with DIR taking precedence at each level > if for some reason both ID and DIR based folders existed. > > Adding such functionality means going outside the scope of current > property inheritance in Org mode. It adds some complexity but maybe > it's warranted to do so here? But, as mentioned, I only got to the > point of thinking about it, I didn't implement it. > > If someone wants to take up the challenge of implementing it then the > starting point should be to modify org-attach-dir, replacing > org-entry-get with something similar to the algorithm mentioned above. > > I might get to it at some point as well, but my motivation lies > elsewhere right now (document-level stuff... see other threads by > me). > > Kind regards > Gustav