From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernt Hansen Subject: Re: Attachments and refiling Date: Thu, 28 Jul 2011 14:04:02 -0400 Message-ID: <87bowecmel.fsf@norang.ca> References: <87ei1rrdzd.fsf@gnu.org> <4e21b345.c74cec0a.7e49.3340@mx.google.com> <87mxg3v32m.fsf@altern.org> <877h76u7l7.fsf@gnu.org> <4e2d91f9.8188ec0a.1582.1369@mx.google.com> <87vcum6d5p.fsf@altern.org> <4e319ffc.1292970a.6d14.1f1a@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:44427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmUwL-0006Cu-8T for emacs-orgmode@gnu.org; Thu, 28 Jul 2011 14:04:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmUwK-00035P-3j for emacs-orgmode@gnu.org; Thu, 28 Jul 2011 14:04:09 -0400 Received: from mho-03-ewr.mailhop.org ([204.13.248.66]:27249 helo=mho-01-ewr.mailhop.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmUwJ-00035L-Vm for emacs-orgmode@gnu.org; Thu, 28 Jul 2011 14:04:08 -0400 In-Reply-To: <4e319ffc.1292970a.6d14.1f1a@mx.google.com> (Darlan Cavalcante Moreira's message of "Thu, 28 Jul 2011 14:31:50 -0300") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Darlan Cavalcante Moreira Cc: Bastien , emacs-orgmode@gnu.org, Gustav =?utf-8?Q?Wikstr=C3=B6m?= > At Thu, 28 Jul 2011 09:51:54 +0200, > Bastien 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 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.