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

[Gustav Wikström]

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