Attachments and refiling

Attachments and refiling

[Gustav Wikström]

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

Is it possible to make attachment-folders move with the headings when
refiling them to other locations?

Regards
Gustav

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

Re: Attachments and refiling

[Bastien]

Hi Gustav,

Gustav Wikström <gustav.erik@gmail.com> writes:

> Is it possible to make attachment-folders move with the headings when
> refiling them to other locations?

I'm not sure what you mean.

Can you give an example?

-- 
 Bastien

Re: Attachments and refiling

[Gustav Wikström]

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

Hello Bastien!

To clarify a bit. Lets say I have a file c:\temp\agenda.org (I'm calling it
file 'a').

When marked with TODO item: done, headings in this file are archived to
another file called c:\temp\archive\agenda.org_archive ('b')

If i use C-c C-a to attach a file to a certain topic in 'a' and then refile
this topic to 'b', when done the attachment still resides in c:\temp\data
and will not be found when looking at the attachment in 'b'.

Thus my question is if it is possible to also refile the attachment so the
attachment-folder resides in c:\temp\archive\data and is avaliable in 'b'?

/Gustav

2011/7/15 Bastien <bzg@altern.org>

> Hi Gustav,
>
> Gustav Wikström <gustav.erik@gmail.com> writes:
>
> > Is it possible to make attachment-folders move with the headings when
> > refiling them to other locations?
>
> I'm not sure what you mean.
>
> Can you give an example?
>
> --
>  Bastien
>

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

Re: Attachments and refiling

[Darlan Cavalcante Moreira]

I use org-attach regularly and consider it to be a great feature of
org-mode. Since I only attach to the sub-tree (instead of to a different
file) I have not this problem. However, sometimes a set the attach
directory of two different headings to the same folder (when it makes
sense) and if org always moved the attached files it would break the other
sub-tree.

An alternative is to change the attach directory in the archived entry to
point to the original attach directory where the files are. When archiving
to a file in a different folder org could ask if it should also move the
attached files or simply change the attach directory accordingly (I would
prefer this as the default if "ask" as the default was considered too
annoying).

--
Darlan

At Fri, 15 Jul 2011 16:55:06 +0200,
Gustav Wikström <gustav.erik@gmail.com> wrote:
> 
> [1  <text/plain; ISO-8859-1 (quoted-printable)>]
> Hello Bastien!
> 
> To clarify a bit. Lets say I have a file c:\temp\agenda.org (I'm calling it
> file 'a').
> 
> When marked with TODO item: done, headings in this file are archived to
> another file called c:\temp\archive\agenda.org_archive ('b')
> 
> If i use C-c C-a to attach a file to a certain topic in 'a' and then refile
> this topic to 'b', when done the attachment still resides in c:\temp\data
> and will not be found when looking at the attachment in 'b'.
> 
> Thus my question is if it is possible to also refile the attachment so the
> attachment-folder resides in c:\temp\archive\data and is avaliable in 'b'?
> 
> /Gustav
> 
> 2011/7/15 Bastien <bzg@altern.org>
> 
> > Hi Gustav,
> >
> > Gustav Wikström <gustav.erik@gmail.com> writes:
> >
> > > Is it possible to make attachment-folders move with the headings when
> > > refiling them to other locations?
> >
> > I'm not sure what you mean.
> >
> > Can you give an example?
> >
> > --
> >  Bastien
> >
> [2  <text/html; ISO-8859-1 (quoted-printable)>]
> 

Re: Attachments and refiling

[Gustav Wikström]

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

Ok. I would really like attachments to be integrated with refiling though
even if it was a non-default option. Another feature that could improve the
use of attachments is to allow links to the attached folders also via the
C-c C-l interface in a similar way as stored links (C-c l ). I.E to get the
attachment-folder as an item in the C-c C-l buffer with TAB-completion.

regards
G

2011/7/16 Darlan Cavalcante Moreira <darcamo@gmail.com>

>
> I use org-attach regularly and consider it to be a great feature of
> org-mode. Since I only attach to the sub-tree (instead of to a different
> file) I have not this problem. However, sometimes a set the attach
> directory of two different headings to the same folder (when it makes
> sense) and if org always moved the attached files it would break the other
> sub-tree.
>
> An alternative is to change the attach directory in the archived entry to
> point to the original attach directory where the files are. When archiving
> to a file in a different folder org could ask if it should also move the
> attached files or simply change the attach directory accordingly (I would
> prefer this as the default if "ask" as the default was considered too
> annoying).
>
> --
> Darlan
>
> At Fri, 15 Jul 2011 16:55:06 +0200,
> Gustav Wikström <gustav.erik@gmail.com> wrote:
> >
> > [1  <text/plain; ISO-8859-1 (quoted-printable)>]
> > Hello Bastien!
> >
> > To clarify a bit. Lets say I have a file c:\temp\agenda.org (I'm calling
> it
> > file 'a').
> >
> > When marked with TODO item: done, headings in this file are archived to
> > another file called c:\temp\archive\agenda.org_archive ('b')
> >
> > If i use C-c C-a to attach a file to a certain topic in 'a' and then
> refile
> > this topic to 'b', when done the attachment still resides in c:\temp\data
> > and will not be found when looking at the attachment in 'b'.
> >
> > Thus my question is if it is possible to also refile the attachment so
> the
> > attachment-folder resides in c:\temp\archive\data and is avaliable in
> 'b'?
> >
> > /Gustav
> >
> > 2011/7/15 Bastien <bzg@altern.org>
> >
> > > Hi Gustav,
> > >
> > > Gustav Wikström <gustav.erik@gmail.com> writes:
> > >
> > > > Is it possible to make attachment-folders move with the headings when
> > > > refiling them to other locations?
> > >
> > > I'm not sure what you mean.
> > >
> > > Can you give an example?
> > >
> > > --
> > >  Bastien
> > >
> > [2  <text/html; ISO-8859-1 (quoted-printable)>]
> >
>

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

Re: Attachments and refiling

[Bastien]

Hi Gustav and Darlan,

one solution I can think of is to set `org-attach-directory' 
to an absolute path instead of "data/" (the current default
value).

This way, refiling an entry will not lose attachments.

I'm considering using "~/.org-data/" as the default value.

What do you think?

-- 
 Bastien

Re: Attachments and refiling

[Bastien]

Hi Gustav,

Gustav Wikström <gustav.erik@gmail.com> writes:

> Another feature that could improve the use of attachments is to allow
> links to the attached folders also via the C-c C-l interface in a
> similar way as stored links (C-c l ). I.E to get the attachment-folder
> as an item in the C-c C-l buffer with TAB-completion.

You can already use (setq org-attach-store-link-p t) to create a link
while attaching a file.  

Since links are deleted as soon as they are inserted, this will be
usable only once.  We can imagine *persistent links* -- and links to
attached files could be a good example of persistent links.  

What do you think?

-- 
 Bastien

Re: Attachments and refiling

[Brian van den Broek]

2011/7/24 Bastien <bzg@altern.org>:
> Hi Gustav and Darlan,
>
> one solution I can think of is to set `org-attach-directory'
> to an absolute path instead of "data/" (the current default
> value).
>
> This way, refiling an entry will not lose attachments.
>
> I'm considering using "~/.org-data/" as the default value.
>
> What do you think?
>
> --
>  Bastien

I don't make much use of attachments, but I would think something like

(setq org-attach-dir (concat org-directory ".data"))

would make more sense. I, at least, prefer to have all of my org
related data living in one directory tree.

Best,

Brian vdB

Re: Attachments and refiling

[Gustav Wikström]

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

I'm leaning towards not moving my archive to a different folder. I like
having the attachments relative.

Are archive- and refile-hooks implemented b.t.w.? This would make it
possible to hack a personal setting, or am I wrong?

/Gustav

2011/7/24 Bastien <bzg@altern.org>

> Hi Gustav and Darlan,
>
> one solution I can think of is to set `org-attach-directory'
> to an absolute path instead of "data/" (the current default
> value).
>
> This way, refiling an entry will not lose attachments.
>
> I'm considering using "~/.org-data/" as the default value.
>
> What do you think?
>
> --
>  Bastien
>

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

Re: Attachments and refiling

[Gustav Wikström]

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

To make org-mode look for attachments in the current sub-tree when using
org-insert-link would simplify the process of "linking" to attached files
(useful at least when exporting). Persistent links, in in this regard, seems
like a nice idea!

/Gustav

2011/7/24 Bastien <bzg@altern.org>

> Hi Gustav,
>
> Gustav Wikström <gustav.erik@gmail.com> writes:
>
> > Another feature that could improve the use of attachments is to allow
> > links to the attached folders also via the C-c C-l interface in a
> > similar way as stored links (C-c l ). I.E to get the attachment-folder
> > as an item in the C-c C-l buffer with TAB-completion.
>
> You can already use (setq org-attach-store-link-p t) to create a link
> while attaching a file.
>
> Since links are deleted as soon as they are inserted, this will be
> usable only once.  We can imagine *persistent links* -- and links to
> attached files could be a good example of persistent links.
>
> What do you think?
>
> --
>  Bastien
>

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

Re: Attachments and refiling

[Bastien]

Gustav Wikström <gustav.erik@gmail.com> writes:

> I'm leaning towards not moving my archive to a different folder. I
> like having the attachments relative.

Okay.  

But as Darlan pointed out, moving the attached files when refiling the
entry might be dangerous, because files in this attached directory can
also be attached in a different subtree.

I don't have a good general solution to this -- if someone has, please
share.

> Are archive- and refile-hooks implemented b.t.w.? 

C-h v org-archive-*-hook TAG
C-h v org-refile-*-hook TAG

helps.

There is `org-after-refile-insert-hook' but there is no
`org-archive-hook'.  I'll consider adding this.

> This would make it
> possible to hack a personal setting, or am I wrong?

You're probably right.  Code is proof.

-- 
 Bastien

Re: Attachments and refiling

[Darlan Cavalcante Moreira]

As I see changing the attach directory to point to the original one is the
easiest solution that has no chances of breaking anything and would keep
attachments working in the refiled/archived sub-trees.

Maybe a org-attach-move-files function could also be implemented to easily
move an attachment directory to a different place. It should move the
directory and automatically set the ATTACH_DIR property to the appropriated
value. Of course org could try to find out if this attach directory is also
used in a different file/sub-tree (maybe search in the agenda files and in
the current directory for org-files using this attach directory) and change
ATTACH_DIR in that file/sub-tree or warn the user before moving the
files. This won't be bullet proof but if the users only set the same attach
directory for headings in the same file, for instance (I do this), then it
would work perfectly.

Then, when the user wants the refiling/archiving process to also move the
attached files it could pass an argument before refiling/archiving and
org-attach-move-files would be called appropriately.

--
Darlan

At Mon, 25 Jul 2011 09:45:24 +0200,
Bastien <bzg@altern.org> wrote:
> 
> Gustav Wikström <gustav.erik@gmail.com> writes:
> 
> > I'm leaning towards not moving my archive to a different folder. I
> > like having the attachments relative.
> 
> Okay.  
> 
> But as Darlan pointed out, moving the attached files when refiling the
> entry might be dangerous, because files in this attached directory can
> also be attached in a different subtree.
> 
> I don't have a good general solution to this -- if someone has, please
> share.
> 
> > Are archive- and refile-hooks implemented b.t.w.? 
> 
> C-h v org-archive-*-hook TAG
> C-h v org-refile-*-hook TAG
> 
> helps.
> 
> There is `org-after-refile-insert-hook' but there is no
> `org-archive-hook'.  I'll consider adding this.
> 
> > This would make it
> > possible to hack a personal setting, or am I wrong?
> 
> You're probably right.  Code is proof.
> 
> -- 
>  Bastien

Re: Attachments and refiling

[Bastien]

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

Re: Attachments and refiling

[suvayu ali]

Hi Bastien,

On Thu, Jul 28, 2011 at 9:51 AM, Bastien <bzg@altern.org> wrote:
> I suggest fixing problem (3) by making `org-attach-dir' defaulting to
> "~/.org-attachments/".

Since most of us like to put our org files under version control,
maybe setting it to

(concat org-directory "/.org-attachments/")

would be a better default?

-- 
Suvayu

Open source is the future. It sets us free.

Re: Attachments and refiling

[Nick Dokos]

suvayu ali <fatkasuvayu+linux@gmail.com> wrote:

> Hi Bastien,
> 
> On Thu, Jul 28, 2011 at 9:51 AM, Bastien <bzg@altern.org> wrote:
> > I suggest fixing problem (3) by making `org-attach-dir' defaulting to
> > "~/.org-attachments/".
> 
> Since most of us like to put our org files under version control,
> maybe setting it to
> 
> (concat org-directory "/.org-attachments/")
> 
> would be a better default?
> 

Why is it better?

Nick

Re: Attachments and refiling

[suvayu ali]

On Thu, Jul 28, 2011 at 3:46 PM, Nick Dokos <nicholas.dokos@hp.com> wrote:
> suvayu ali <fatkasuvayu+linux@gmail.com> wrote:
>
>> Hi Bastien,
>>
>> On Thu, Jul 28, 2011 at 9:51 AM, Bastien <bzg@altern.org> wrote:
>> > I suggest fixing problem (3) by making `org-attach-dir' defaulting to
>> > "~/.org-attachments/".
>>
>> Since most of us like to put our org files under version control,
>> maybe setting it to
>>
>> (concat org-directory "/.org-attachments/")
>>
>> would be a better default?
>>
>
> Why is it better?
>

Then the attachments can also be version controlled. If it is under
~/.org-attachments/, then it is outside the directory tree.

> Nick
>


-- 
Suvayu

Open source is the future. It sets us free.

Re: Attachments and refiling

[Nick Dokos]

suvayu ali <fatkasuvayu+linux@gmail.com> wrote:

> On Thu, Jul 28, 2011 at 3:46 PM, Nick Dokos <nicholas.dokos@hp.com> wrote:
> > suvayu ali <fatkasuvayu+linux@gmail.com> wrote:
> >
> >> Hi Bastien,
> >>
> >> On Thu, Jul 28, 2011 at 9:51 AM, Bastien <bzg@altern.org> wrote:
> >> > I suggest fixing problem (3) by making `org-attach-dir' defaulting to
> >> > "~/.org-attachments/".
> >>
> >> Since most of us like to put our org files under version control,
> >> maybe setting it to
> >>
> >> (concat org-directory "/.org-attachments/")
> >>
> >> would be a better default?
> >>
> >
> > Why is it better?
> >
> 
> Then the attachments can also be version controlled. If it is under
> ~/.org-attachments/, then it is outside the directory tree.
> 

D'oh! thanks.

Nick

Re: Attachments and refiling

[Darlan Cavalcante Moreira]

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

At Thu, 28 Jul 2011 09:51:54 +0200,
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

Re: Attachments and refiling

[Bernt Hansen]

> At Thu, 28 Jul 2011 09:51:54 +0200,
> 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.  

Darlan Cavalcante Moreira <darcamo@gmail.com> 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.

Re: Attachments and refiling

[Gustav Wikström]

[-- 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 --]

Re: Attachments and refiling

[Gustav Wikström]

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

What about being able to link to attachments in a similar way as one links
to files or web-pages? Using [[attachment:some_file.sql][some link name]] ?
Comments? Problems with this?

2011/7/25 Gustav Wikström <gustav.erik@gmail.com>

> To make org-mode look for attachments in the current sub-tree when using
> org-insert-link would simplify the process of "linking" to attached files
> (useful at least when exporting). Persistent links, in in this regard, seems
> like a nice idea!
>
> /Gustav
>
> 2011/7/24 Bastien <bzg@altern.org>
>
>> Hi Gustav,
>>
>> Gustav Wikström <gustav.erik@gmail.com> writes:
>>
>> > Another feature that could improve the use of attachments is to allow
>> > links to the attached folders also via the C-c C-l interface in a
>> > similar way as stored links (C-c l ). I.E to get the attachment-folder
>> > as an item in the C-c C-l buffer with TAB-completion.
>>
>> You can already use (setq org-attach-store-link-p t) to create a link
>> while attaching a file.
>>
>> Since links are deleted as soon as they are inserted, this will be
>> usable only once.  We can imagine *persistent links* -- and links to
>> attached files could be a good example of persistent links.
>>
>> What do you think?
>>
>> --
>>  Bastien
>>
>
>

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

Re: Attachments and refiling

[Darlan Cavalcante Moreira]

I requested this some time ago [1]. While there is not a built-in attach
link type, org provides you with ways to easily create this functionality.

In the setup part in my org-files I put
--8<---------------cut here---------------start------------->8---
#+LINK: attach elisp:(org-open-file (org-attach-expand "%s"))
--8<---------------cut here---------------end--------------->8---

Now I can use the "attach" link type, but org will ask me if I want to
allow executing the elisp code. To avoid this you can even set
org-confirm-elisp-link-function to nil (I don't like this because it allows
any elisp code in links) or you can set org-confirm-elisp-link-not-regexp
appropriately.

In my case I use
: (setq org-confirm-elisp-link-not-regexp "org-open-file")


This works very well.

--
Darlan

[1] http://www.mail-archive.com/emacs-orgmode@gnu.org/msg37613.html

At Fri, 29 Jul 2011 10:33:37 +0200,
Gustav Wikström <gustav.erik@gmail.com> wrote:
> 
> [1  <text/plain; ISO-8859-1 (quoted-printable)>]
> What about being able to link to attachments in a similar way as one links
> to files or web-pages? Using [[attachment:some_file.sql][some link name]] ?
> Comments? Problems with this?
> 
> 2011/7/25 Gustav Wikström <gustav.erik@gmail.com>
> 
> > To make org-mode look for attachments in the current sub-tree when using
> > org-insert-link would simplify the process of "linking" to attached files
> > (useful at least when exporting). Persistent links, in in this regard, seems
> > like a nice idea!
> >
> > /Gustav
> >
> > 2011/7/24 Bastien <bzg@altern.org>
> >
> >> Hi Gustav,
> >>
> >> Gustav Wikström <gustav.erik@gmail.com> writes:
> >>
> >> > Another feature that could improve the use of attachments is to allow
> >> > links to the attached folders also via the C-c C-l interface in a
> >> > similar way as stored links (C-c l ). I.E to get the attachment-folder
> >> > as an item in the C-c C-l buffer with TAB-completion.
> >>
> >> You can already use (setq org-attach-store-link-p t) to create a link
> >> while attaching a file.
> >>
> >> Since links are deleted as soon as they are inserted, this will be
> >> usable only once.  We can imagine *persistent links* -- and links to
> >> attached files could be a good example of persistent links.
> >>
> >> What do you think?
> >>
> >> --
> >>  Bastien
> >>
> >
> >
> [2  <text/html; ISO-8859-1 (quoted-printable)>]
> 

Re: Attachments and refiling

[Matt Lundin]

Gustav Wikström <gustav.erik@gmail.com> writes:

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

One possibility is to advise the function org-attach-dir to call
org-attach-set-directory (and, optionally, org-attach-set-inherit) if
the entry does not already have an ATTACH_DIR property:

--8<---------------cut here---------------start------------->8---
(defadvice org-attach-dir (before my-org-attach-set-dir-before-attach activate)
  "Prompt for attachment directory (thus preempting org-get-id)."
  (unless (org-entry-get nil "ATTACH_DIR" 'inherit)
    (org-attach-set-directory)))
--8<---------------cut here---------------end--------------->8---

This allows one to enter the name of the directory *before* org attaches
the file. This is the way I use org-attach, as I prefer human-readable
directories to UUIDs.

Best,
Matt

Re: Attachments and refiling

[Bastien]

Hi Darlan,

Darlan Cavalcante Moreira <darcamo@gmail.com> writes:

> I requested this some time ago [1]. While there is not a built-in attach
> link type, org provides you with ways to easily create this functionality.
>
> In the setup part in my org-files I put
> #+LINK: attach elisp:(org-open-file (org-attach-expand "%s"))
>
> Now I can use the "attach" link type, but org will ask me if I want to
> allow executing the elisp code. To avoid this you can even set
> org-confirm-elisp-link-function to nil (I don't like this because it allows
> any elisp code in links) or you can set org-confirm-elisp-link-not-regexp
> appropriately.
>
> In my case I use
> : (setq org-confirm-elisp-link-not-regexp "org-open-file")
>
> This works very well.

This is a nice and useful hack -- I added it to Worg/org-hacks.org.

Thanks!

-- 
 Bastien

Re: Attachments and refiling

[Darlan Cavalcante Moreira]

Hello Bastien,
I'm glad to help (even if such a small contribution).

The downside of this hack is that it does not work when you export the
buffer. If you use the file: link type then the link will works when you
export the org buffer, but you have to type the whole path of the attached
file. Therefore, there is this trade-off for now.

There is probably a way to make the attach link type also work when
exporting the org buffer, but since I don't need this right now I didn't
search how to do it.

--
Darlan

At Thu, 18 Aug 2011 19:33:37 +0200,
Bastien <bzg@altern.org> wrote:
> 
> Hi Darlan,
> 
> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
> 
> > I requested this some time ago [1]. While there is not a built-in attach
> > link type, org provides you with ways to easily create this functionality.
> >
> > In the setup part in my org-files I put
> > #+LINK: attach elisp:(org-open-file (org-attach-expand "%s"))
> >
> > Now I can use the "attach" link type, but org will ask me if I want to
> > allow executing the elisp code. To avoid this you can even set
> > org-confirm-elisp-link-function to nil (I don't like this because it allows
> > any elisp code in links) or you can set org-confirm-elisp-link-not-regexp
> > appropriately.
> >
> > In my case I use
> > : (setq org-confirm-elisp-link-not-regexp "org-open-file")
> >
> > This works very well.
> 
> This is a nice and useful hack -- I added it to Worg/org-hacks.org.
> 
> Thanks!
> 
> -- 
>  Bastien

Re: Attachments and refiling

[Bastien]

Hi Darlan,

Darlan Cavalcante Moreira <darcamo@gmail.com> writes:

> There is probably a way to make the attach link type also work when
> exporting the org buffer, but since I don't need this right now I didn't
> search how to do it.

You could use a `org-export-preprocess-hook' to convert those "attach"
links into proper "file" links.

-- 
 Bastien

Re: Attachments and refiling

[Darlan Cavalcante Moreira]

At Fri, 19 Aug 2011 10:46:26 +0200,
Bastien <bzg@altern.org> wrote:

What about org-add-link-type?

Besides the new link type name, org-add-link-type can receives two
functions, one used to follow the link and another to export the link.

I was able to make the attach link type work by using org-add-link-type,
where the "follow" function is practically the same code I have used
with #+LINK.

However, I could not make the the "export" part work because I can't use
org-attach-expand in it. Therefore, I don't know how to get the attach
directory inside a function that I can pass to org-add-link-type as the
export function. Unfortunately, my elisp skills are very limited to go any
further for now.

--
Darlan

> 
> Hi Darlan,
> 
> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
> 
> > There is probably a way to make the attach link type also work when
> > exporting the org buffer, but since I don't need this right now I didn't
> > search how to do it.
> 
> You could use a `org-export-preprocess-hook' to convert those "attach"
> links into proper "file" links.
> 
> -- 
>  Bastien

Re: Attachments and refiling

[Bastien]

Hi Darlan,

Darlan Cavalcante Moreira <darcamo@gmail.com> writes:

> At Fri, 19 Aug 2011 10:46:26 +0200,
> Bastien <bzg@altern.org> wrote:
>
> What about org-add-link-type?

Mmhh..  yes.  We should be able to use something like:

  (org-add-link-type "attach" 'org-attach-open 'org-attach-export)

> However, I could not make the the "export" part work because I can't use
> org-attach-expand in it. Therefore, I don't know how to get the attach
> directory inside a function that I can pass to org-add-link-type as the
> export function. 

That's not possible for now.  That's something we can keep in mind 
while working an a new export engine: exporting part of the content 
should be done in a context-aware fashion, where it's possible to 
get the value of org-attach-dir.

> Unfortunately, my elisp skills are very limited to go any further for
> now.

Even with good elisp skills I'm afraid we cannot achieve this for 
the moment.  

HTH,

-- 
 Bastien

Re: Attachments and refiling

[Darlan Cavalcante Moreira]

At Wed, 24 Aug 2011 16:12:01 +0200,
Bastien <bzg@altern.org> wrote:
> 
> Hi Darlan,
> 
> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
> 
> > At Fri, 19 Aug 2011 10:46:26 +0200,
> > Bastien <bzg@altern.org> wrote:
> >
> > What about org-add-link-type?
> 
> Mmhh..  yes.  We should be able to use something like:
> 
>   (org-add-link-type "attach" 'org-attach-open 'org-attach-export)
> 
> > However, I could not make the the "export" part work because I can't use
> > org-attach-expand in it. Therefore, I don't know how to get the attach
> > directory inside a function that I can pass to org-add-link-type as the
> > export function. 
> 
> That's not possible for now.  That's something we can keep in mind 
> while working an a new export engine: exporting part of the content 
> should be done in a context-aware fashion, where it's possible to 
> get the value of org-attach-dir.

Thanks for the confirmation Bastien. At least for me the export part is not
very important right now. A context aware export engine would make this
easy to achieve with org-add-link-type and probably open up many other
possibilities, but I understand it is a lot of work.

> 
> > Unfortunately, my elisp skills are very limited to go any further for
> > now.
> 
> Even with good elisp skills I'm afraid we cannot achieve this for 
> the moment.  
> 
> HTH,
> 
> -- 
>  Bastien

--
Darlan

Re: Attachments and refiling

[Gustav Wikström]

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

Thanks for this. Added it to my settings for now =)

/Gustav

2011/8/2 Matt Lundin <mdl@imapmail.org>

> Gustav Wikström <gustav.erik@gmail.com> writes:
>
> > 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.
> >
> > 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.
>
> One possibility is to advise the function org-attach-dir to call
> org-attach-set-directory (and, optionally, org-attach-set-inherit) if
> the entry does not already have an ATTACH_DIR property:
>
> --8<---------------cut here---------------start------------->8---
> (defadvice org-attach-dir (before my-org-attach-set-dir-before-attach
> activate)
>  "Prompt for attachment directory (thus preempting org-get-id)."
>  (unless (org-entry-get nil "ATTACH_DIR" 'inherit)
>    (org-attach-set-directory)))
> --8<---------------cut here---------------end--------------->8---
>
> This allows one to enter the name of the directory *before* org attaches
> the file. This is the way I use org-attach, as I prefer human-readable
> directories to UUIDs.
>
> Best,
> Matt
>

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