In case the "not worrying about where.." in (1) is part the purpose of the attachment functionality the idea of an absolute path seems sound. I agree with it being a nice feature, and probably the best to have as default.
However I think it also is nice to also be able to use custom names to attachment folders. And it would be nice be able to use some logic with this, like automatically setting the folder name to the same as the heading it's attached to. And to allow properties on a file/heading/sub-tree basis which defines the base-path to where attachments to that particular file/heading/sub-tree should reside on the system, relative or non-relative. This would allow for more atomic solutions if i'm writing a document on the side of my main setup and want to add some attachments in the same path.
This adds a bit to the complexity of designing the functionality, and questions about refiling and archiving arise.. But maybe just adding a warning for these events might be enough as a first step. Although, with file-properties for attachment directories it might be possible to ask if the attachment-dir should also be moved (or copied) to this new location.
But still, it is a really nice feature to have control over the attachments. So from my point of view it seems sound to try to reason about different solutions to this or at least keep it in mind for future functionality.
Just some thoughts
Gustav
On Thu, Jul 28, 2011 at 9:51 AM, Bastien
<bzg@altern.org> 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