Re: Feature Request: attach link type

[Darlan Cavalcante Moreira <darcamo@gmail.com>]

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