Re: Attachments and refiling

["Gustav Wikström" <gustav.erik@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3343 bytes --]