From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Gustav_Wikstr=F6m?= Subject: Re: Attachments and refiling Date: Fri, 29 Jul 2011 09:27:34 +0200 Message-ID: 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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf3042719e1c4a4f04a93037d1 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:58262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmhTv-0002Cn-8d for emacs-orgmode@gnu.org; Fri, 29 Jul 2011 03:27:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmhTs-0000aw-RZ for emacs-orgmode@gnu.org; Fri, 29 Jul 2011 03:27:39 -0400 Received: from mail-iy0-f169.google.com ([209.85.210.169]:44043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmhTs-0000ai-GU for emacs-orgmode@gnu.org; Fri, 29 Jul 2011 03:27:36 -0400 Received: by iyb14 with SMTP id 14so4729180iyb.0 for ; Fri, 29 Jul 2011 00:27:35 -0700 (PDT) In-Reply-To: <87vcum6d5p.fsf@altern.org> 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: Bastien Cc: emacs-orgmode@gnu.org --20cf3042719e1c4a4f04a93037d1 Content-Type: text/plain; charset=ISO-8859-1 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 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 > --20cf3042719e1c4a4f04a93037d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In case the "not worrying about where.." in (1) is part the purpo= se 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 de= fault.

However I think it also is nice to also be able to use custo= m names to attachment folders. And it would be nice be able to use some log= ic 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/su= b-tree=A0basis which defines the base-path to where attachments to that par= ticular file/heading/sub-tree=A0should reside on the system, relative or no= n-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 func= tionality, and questions about refiling and archiving arise.. But maybe jus= t adding a warning for these events might be enough as a first step. Althou= gh, 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 loc= ation.

But still, it is a really nice feature to have control = over the attachments.=A0So from my point of view it seems sound to try to r= eason about different solutions to this or at least keep it in mind for fut= ure functionality.

Just some thoughts
Gustav

On Thu, Jul 28, 2011 at 9:51 AM, Bastien <bzg@altern.org> w= rote:
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
=A0 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
=A0 there is no problem when moving an entry with an explicit ATTACH_DIR.<= br>
3. Refiling/archiving subtrees lose track of some attachments when the
=A0 attach directory "data/" is *relative* to the org file (whic= h is the
=A0 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
=A0 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/". =A0I

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!

--
=A0Bastien

--20cf3042719e1c4a4f04a93037d1--