Myles English <mylesengl...@gmail.com> writes: > Hi Eric, > > I am glad you like it. > > e...@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 :)
