Re: [O] [RFC] Link-type for attachments, more attach options

[Ihor Radchenko]

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 <address@hidden> writes:

> Hi Ihor,
>
>> -----Original Message-----
>> From: Ihor Radchenko <address@hidden>
>> Sent: den 27 juli 2019 16:56
>> To: Gustav Wikström <address@hidden>; Nicolas Goaziou <address@hidden>
>> Cc: address@hidden
>> 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