Re: [O] Attachments and refiling

[Darlan Cavalcante Moreira]

Regarding (2), is this a design decision? Currently I have the ATTACH_DIR
property of some headings set to a relative path from the org file and it
works perfectly. That is, it is possible to use either absolute or relative
path for the ATTACH_DIR property right now.

But if this is a design decision then I should not consider this behavior
as granted, right?

Also, Suvayu's suggestion for the default attachments directory is the best
solution IMHO. That is, the default attach directory should be relative to
org-directory.
  
--
Darlan

At Thu, 28 Jul 2011 09:51:54 +0200,
Bastien <address@hidden> wrote:
> 
> Hi Darlan,
> 
> here is how I see the situation regarding attachments:
> 
> 1. org-attach.el is nice because it makes it easy to attach a file to a
>    task, while not *worrying* about where the file is on the harddrive.
> 
> 2. Adding an ATTACH_DIR property will always add an absolute path, so
>    there is no problem when moving an entry with an explicit ATTACH_DIR.
> 
> 3. Refiling/archiving subtrees lose track of some attachments when the
>    attach directory "data/" is *relative* to the org file (which is the
>    default) and when the target org file is not in the same directory.
> 
> 4. Moving an entry with an ATTACH_DIR_INHERIT will lose attachments 
>    when the ATTACH_DIR of the target entry is different.
> 
> (3) and (4) are two distinct problems.
> 
> I suggest fixing problem (3) by making `org-attach-dir' defaulting to
> "~/.org-attachments/".  I
> 
> I suggest fixing problem (4) by explicitely replacing ATTACH_DIR_INHERIT
> with the corresponding ATTACH_DIR when the target subtree has a
> different ATTACH_DIR.
> 
> The core idea is that I want to avoid moving files themselves: I think
> it's a risky road, and I hope the solutions above will make this road
> unnecessary.
> 
> I'm interested in feedback and ideas about such proposed changes.  
> 
> Thanks a lot!
> 
> -- 
>  Bastien