Re: capture, attach, link files from web

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Myles English <mylesenglish@gmail.com> writes:

> Hi Eric,
>
> I am glad you like it.
>
> eric@ericabrahamsen.net writes:
>
> [..]
>
>> Rather than sending downloaded files to $TMPDIR, it might be nice to
>> have them just use whatever dir org-attach would have used. I use
>> org-attach from time to time, and notice that everything ends up under
>> ~/org/data/. I haven't actually investigated why that happens (I've got
>> org-directory set to ~/org/), mostly because it strikes me as a fine
>> default. When we've got that directory, setting a different TMPDIR seems
>> unnecessary. I'll admit part of my hesitation comes from the fact that
>> "TMPDIR" sounds like it's going to get automatically deleted at some
>> point.
>
> The $TMPDIR was just an environment variable I had set already so
> assumed it was semi-standard (doesn't everyone have a $TMPDIR?).  When
> my function calls:
>
> (org-attach-attach (concat tmpdir "/" fname) nil 'mv)
>
> it moves the file from $TMPDIR to the attachment directory, amongst
> other things no doubt.

Whoops, should have looked at the signature of `org-attach-attach' more
closely...

> The attachment directory is decided by the (org-attach-dir) function and
> I presume the new file could be downloaded straight there and then the
> task/heading would have to be synchronised with it's attachments to get
> the new file to show up in the heading's properties.
>
>> I've often thought it would be nice to link to images in an org file
>> with http: links, then at some arbitrary point in time call a
>> hypothetical org-localize-external-resources command. That command would
>> wget all the external resources, put them somewhere local, and switch
>> the links to the file: type. Just a thought.
>
> Good idea.  I look forward to your clever implementation with proper
> indenting and informative comments.

I'll get right on it :)