emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Attachments and refiling


From: Bernt Hansen
Subject: Re: [O] Attachments and refiling
Date: Thu, 28 Jul 2011 14:04:02 -0400
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux)

> 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.  

Darlan Cavalcante Moreira <address@hidden> writes:

> 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.

I've used attachments in the past to *copy* attached files somewhere
into my org git repository (~/git/org) with attachments under
~/git/org/data/...

Since the files are copied I can refile the task with the attachment
anywhere in the same git repository without worrying about the details
of exactly where it lives.  Since then I've stopped using attachments
regularly but I still have archived tasks with attachments in my git
repo.

None of my existing entries have ever specified an ATTACH_DIR*
property.  Whatever solution is arrived at from this thread I would like
my existing (old) attachments to still be retrievable.

-Bernt

PS. Darlan: Please don't top-post, it makes articles much harder to read.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]