Feature Request: attach link type

Feature Request: attach link type

[Darlan Cavalcante Moreira]

Hello List,

One org-mode feature that I find extremely useful is org-attach. I use it
frequently as an easy way to store files associated with a task (in fact,
any sub-tree) without worrying too much about where the files are located
(for some specific sub-trees I like to set the attach directory).

However, sometimes I need to put a link to an attached file in the text in
its sub-tree. Up to now I just used the path to the file, but that required
me to locate where the file is located in order to insert the link. This is
not a lot of work, but destroys the beauty of attached files, IMHO, and I
think some "attach link type" would be a better solution.

Using the functions already provided by org-attach I could get
#+LINK: attach elisp:(org-open-file (org-attach-expand "%s"))
However, I always have to confirm the execution of the elisp code. It would
be better if this link type was already provided in org (possible when
org-attach is loaded). Besides, org inline images should work with this
link type.


Other useful things (just random thoughts) could be:
 - Perform some operation when a file is attached, such as replacing
   white-spaces in the file-name by underscores
 - When a file is attached a link to it could be stored in the kill ring,
   in case the user want to insert it in the current text. Alternatively,
   an interactive function to insert a link to an attached file (using the
   same completions we already get for opening attached files) would also
   be very handy.

--
Darlan

Re: Feature Request: attach link type

[Bastien]

Hi Darlan,

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

> Using the functions already provided by org-attach I could get
> #+LINK: attach elisp:(org-open-file (org-attach-expand "%s"))
> However, I always have to confirm the execution of the elisp code. 

You want to set `org-confirm-elisp-link-function' to nil.

> Other useful things (just random thoughts) could be:
>  - Perform some operation when a file is attached, such as replacing
>    white-spaces in the file-name by underscores

IMHO this goes beyond what org-attach.el should do: attach files.
Besides, that would require even more confirmation steps.

>  - When a file is attached a link to it could be stored in the kill ring,
>    in case the user want to insert it in the current text. Alternatively,
>    an interactive function to insert a link to an attached file (using the
>    same completions we already get for opening attached files) would also
>    be very handy.

Yes, good idea.

From latest git, set `org-attach-store-link-p' to `t' if you want a link
to be stored in `org-stored-links' when attaching a file.

Thanks,

-- 
 Bastien

-- 
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Feature Request: attach link type

[Darlan Cavalcante Moreira]

At Thu, 03 Mar 2011 11:18:06 +0100,
Bastien <bzg@altern.org> wrote:
> 
> Hi Darlan,
> 
> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
> 
> > Using the functions already provided by org-attach I could get
> > #+LINK: attach elisp:(org-open-file (org-attach-expand "%s"))
> > However, I always have to confirm the execution of the elisp code. 
> 
> You want to set `org-confirm-elisp-link-function' to nil.

Thanks Bastien.

I knew there was some variable to control this for all elisp links. I would
prefer not to set this to nil, since I like the confirmation for other
elisp links and since links for attached files are common for me I thought
it could be a "built-in link". But that's OK.

> 
> > Other useful things (just random thoughts) could be:
> >  - Perform some operation when a file is attached, such as replacing
> >    white-spaces in the file-name by underscores
> 
> IMHO this goes beyond what org-attach.el should do: attach files.
> Besides, that would require even more confirmation steps.

My common use scenario for org-attach is to store files associated to a
sub-tree. For instance, when I receive a file by E-mail that I need to read
I create a task for it and attach the file. I usually need to change the
file name, since I don't like spaces and If would be practical if I could
attach the file as it is and know that org-attach would store it the way I
like. Is there a hook I could use to do this myself then? (I'm not a lisp
programmer, but think I can google tips about how to do this).

> 
> >  - When a file is attached a link to it could be stored in the kill ring,
> >    in case the user want to insert it in the current text. Alternatively,
> >    an interactive function to insert a link to an attached file (using the
> >    same completions we already get for opening attached files) would also
> >    be very handy.
> 
> Yes, good idea.
> 
> From latest git, set `org-attach-store-link-p' to `t' if you want a link
> to be stored in `org-stored-links' when attaching a file.

This is even better then storing it in the kill ring. I noticed that the
link points to the location of the original file and not to the location
where it was attached (which is what thought it would do). Is this what you
intended?

> 
> Thanks,
> 
> -- 
>  Bastien


--
Darlan

Re: Re: Feature Request: attach link type

[Sébastien Vauban]

Hi Darlan and Bastien,

Darlan Cavalcante Moreira wrote:
>> > Other useful things (just random thoughts) could be:
>> >  - Perform some operation when a file is attached, such as replacing
>> >    white-spaces in the file-name by underscores
>> 
>> IMHO this goes beyond what org-attach.el should do: attach files.
>> Besides, that would require even more confirmation steps.
>
> My common use scenario for org-attach is to store files associated to a
> sub-tree. For instance, when I receive a file by E-mail that I need to read
> I create a task for it and attach the file. I usually need to change the
> file name, since I don't like spaces and If would be practical if I could
> attach the file as it is and know that org-attach would store it the way I
> like. Is there a hook I could use to do this myself then? (I'm not a lisp
> programmer, but think I can google tips about how to do this).

Just to comment on that point: reworking the filename is exactly what Gnus do
with attachment files, once you want to save them. It (optionally) do whatever
is needed to make them better, such as removing spaces, replacing accents,
etc...

Best regards,
  Seb

-- 
Sébastien Vauban

Re: Re: Feature Request: attach link type

[Darlan Cavalcante Moreira]

I once tried Gnus, but end up using Wanderlust, which is pretty good. Along
with org-contacts I'm becoming more and more motivated to try Gnus again. I
try to have a look at it. Thanks.


At Fri, 04 Mar 2011 22:56:41 +0100,
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
> 
> Hi Darlan and Bastien,
> 
> Darlan Cavalcante Moreira wrote:
> >> > Other useful things (just random thoughts) could be:
> >> >  - Perform some operation when a file is attached, such as replacing
> >> >    white-spaces in the file-name by underscores
> >> 
> >> IMHO this goes beyond what org-attach.el should do: attach files.
> >> Besides, that would require even more confirmation steps.
> >
> > My common use scenario for org-attach is to store files associated to a
> > sub-tree. For instance, when I receive a file by E-mail that I need to read
> > I create a task for it and attach the file. I usually need to change the
> > file name, since I don't like spaces and If would be practical if I could
> > attach the file as it is and know that org-attach would store it the way I
> > like. Is there a hook I could use to do this myself then? (I'm not a lisp
> > programmer, but think I can google tips about how to do this).
> 
> Just to comment on that point: reworking the filename is exactly what Gnus do
> with attachment files, once you want to save them. It (optionally) do whatever
> is needed to make them better, such as removing spaces, replacing accents,
> etc...
> 
> Best regards,
>   Seb
> 
> -- 
> Sébastien Vauban
> 
> 

Re: Feature Request: attach link type

[Bastien]

Hi Darlan,

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

> I knew there was some variable to control this for all elisp links. I would
> prefer not to set this to nil, since I like the confirmation for other
> elisp links and since links for attached files are common for me I thought
> it could be a "built-in link". But that's OK.

I just introduced `org-confirm-elisp-link-not-regexp' which allows the
user to avoid confirmation step for elisp code matching a regexp.  Hope
that helps in your case.

> My common use scenario for org-attach is to store files associated to a
> sub-tree. For instance, when I receive a file by E-mail that I need to read
> I create a task for it and attach the file. I usually need to change the
> file name, since I don't like spaces and If would be practical if I could
> attach the file as it is and know that org-attach would store it the way I
> like. Is there a hook I could use to do this myself then? (I'm not a lisp
> programmer, but think I can google tips about how to do this).

I've been working a bit on your idea, it's possible to create a function
and to use it to rename a file when the user is attaching it - but there
are problems: for example, if this function changes, then there will be
*several* attachements for the same file...  we don't want that.

So, renaming the file belongs elsewhere IMHO.

>> >  - When a file is attached a link to it could be stored in the kill ring,
>> >    in case the user want to insert it in the current text. Alternatively,
>> >    an interactive function to insert a link to an attached file (using the
>> >    same completions we already get for opening attached files) would also
>> >    be very handy.
>> 
>> Yes, good idea.
>> 
>> From latest git, set `org-attach-store-link-p' to `t' if you want a link
>> to be stored in `org-stored-links' when attaching a file.
>
> This is even better then storing it in the kill ring. I noticed that the
> link points to the location of the original file and not to the location
> where it was attached (which is what thought it would do). Is this what you
> intended?

Yes.  Since the file is now also available as an attachment, a link to
the source file might be useful, while a link to the attached file is a
bit redundant with what org-attach allows you to do (get the file).

Does that make sense?

Thanks,

-- 
 Bastien

Re: Feature Request: attach link type

[Darlan Cavalcante Moreira]

At Sat, 05 Mar 2011 10:14:17 +0100,
Bastien <bzg@altern.org> wrote:

Hello Bastien,

Sorry for the late reply. For some reason (path related) Emacs was loading
an older version of org instead of the one from git and I wasn't seeing your
changes.

>
> Hi Darlan,
> 
> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
> 
> > I knew there was some variable to control this for all elisp links. I would
> > prefer not to set this to nil, since I like the confirmation for other
> > elisp links and since links for attached files are common for me I thought
> > it could be a "built-in link". But that's OK.
> 
> I just introduced `org-confirm-elisp-link-not-regexp' which allows the
> user to avoid confirmation step for elisp code matching a regexp.  Hope
> that helps in your case.
>

I tested this and it works perfectly. Thanks!

> > My common use scenario for org-attach is to store files associated to a
> > sub-tree. For instance, when I receive a file by E-mail that I need to read
> > I create a task for it and attach the file. I usually need to change the
> > file name, since I don't like spaces and If would be practical if I could
> > attach the file as it is and know that org-attach would store it the way I
> > like. Is there a hook I could use to do this myself then? (I'm not a lisp
> > programmer, but think I can google tips about how to do this).
> 
> I've been working a bit on your idea, it's possible to create a function
> and to use it to rename a file when the user is attaching it - but there
> are problems: for example, if this function changes, then there will be
> *several* attachements for the same file...  we don't want that.
> 
> So, renaming the file belongs elsewhere IMHO.

I understand. I may be using org-attach in a way a little different from
what it was originally intended to.

> 
> >> >  - When a file is attached a link to it could be stored in the kill ring,
> >> >    in case the user want to insert it in the current text. Alternatively,
> >> >    an interactive function to insert a link to an attached file (using the
> >> >    same completions we already get for opening attached files) would also
> >> >    be very handy.
> >> 
> >> Yes, good idea.
> >> 
> >> From latest git, set `org-attach-store-link-p' to `t' if you want a link
> >> to be stored in `org-stored-links' when attaching a file.
> >
> > This is even better then storing it in the kill ring. I noticed that the
> > link points to the location of the original file and not to the location
> > where it was attached (which is what thought it would do). Is this what you
> > intended?
> 
> Yes.  Since the file is now also available as an attachment, a link to
> the source file might be useful, while a link to the attached file is a
> bit redundant with what org-attach allows you to do (get the file).
> 
> Does that make sense?
>
> Thanks,
> 
> -- 
>  Bastien

I think yes and no, depending on what the user wants to do.

I my case I use org-attach as a way to store files related to org that *I
don't need to access outside org-mode*. For files that I access outside
org-mode I don't attach it at all. I just use links to the file when I need
to. Therefore I almost always delete the original file after attaching it
and that's why IMHO the stored link should point to the location where the
file was attached to.

Again, maybe I'm just using org-attach in a way a little different from
what it was originally intended to. That's why for me It makes sense to
create an attach link type.

--
Darlan Cavalcante

Re: Re: Feature Request: attach link type

[Bastien]

Hi Darlan,

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

> I think yes and no, depending on what the user wants to do.
>
> I my case I use org-attach as a way to store files related to org that *I
> don't need to access outside org-mode*. For files that I access outside
> org-mode I don't attach it at all. I just use links to the file when I need
> to. Therefore I almost always delete the original file after attaching it
> and that's why IMHO the stored link should point to the location where the
> file was attached to.
>
> Again, maybe I'm just using org-attach in a way a little different from
> what it was originally intended to. That's why for me It makes sense to
> create an attach link type.

Thanks for the explanations -- I've now allowed org-attach-store-link-p
to be set to 'attached so that the link points to the attached location
instead of the original location.

Let me know if it does the right thing for you.

Best,

-- 
 Bastien

Re: Re: Feature Request: attach link type

[Darlan Cavalcante Moreira]

Thank you Bastien.
It works as expected.

--
Darlan

At Thu, 10 Mar 2011 11:24:26 +0100,
Bastien <bzg@altern.org> wrote:
> 
> Hi Darlan,
> 
> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
> 
> > I think yes and no, depending on what the user wants to do.
> >
> > I my case I use org-attach as a way to store files related to org that *I
> > don't need to access outside org-mode*. For files that I access outside
> > org-mode I don't attach it at all. I just use links to the file when I need
> > to. Therefore I almost always delete the original file after attaching it
> > and that's why IMHO the stored link should point to the location where the
> > file was attached to.
> >
> > Again, maybe I'm just using org-attach in a way a little different from
> > what it was originally intended to. That's why for me It makes sense to
> > create an attach link type.
> 
> Thanks for the explanations -- I've now allowed org-attach-store-link-p
> to be set to 'attached so that the link points to the attached location
> instead of the original location.
> 
> Let me know if it does the right thing for you.
> 
> Best,
> 
> -- 
>  Bastien