org-download
org-download copied to clipboard
handling non-image files and urls
Looking at this very usefull mode again, I would like to configure some rules on how to treat non-image files for input method drag&drop.
- if (= file-type (and (any exept these-exclusions) (not image))):
- treat file the as usual (downloading and referencing it) but skip the markup for image files
- and treat url-resource as text or binary file if possible
- or insert org-link only
- toggle these rules for non-image files
I tried to find the point of decision about the type of the file in the source org-download.el. But as far as I understand the code untill now, there are multiple points of decision about the type of the file or url. Could those be combined into one in order to be able to hook the behaviour for non-image files?
I just found an example of the same functionality here Drag images and files onto org-mode and insert a link to them It uses keybindings to decide between the different use cases. That may be the way to go.
maybe we need attachment dispatcher? just like org-agenda?
This would be very useful. I would like to use this to download and attach a PDF file, but it refuses because the MIME-type in the HTTP headers is not image/...
.
I also think it would be great to extend org-download so you can DnD arbitrary files to an org-mode heading. I often have PDF files (and other types) I'd like to drop in.
I would also absolutely love it if this were possible.
Isn't atleast part of this possible using org-web-tools ?
@shrysr Specifically, this function does it, which uses org-web-tools
. Maybe I should add it to that package too: https://github.com/alphapapa/unpackaged.el#download-and-attach-remote-files
I've modified the code to handle non-image files. As a test, I drag-and-dropped pdf files from Nautilus to org-mode.
Please test to see if more scenarios are needed to work.
Is it possible that a pdf link from browser, could also be pasted similarly as in Nautilus case?
You can now drag-and-drop a PDF link from a browser to either dired-mode
or org-mode
. Please test and let me know of other ideas to extend this.
tested it. It works great. Thank you for implementing it.
I am having some problems with this. I am using doom emacs with a pretty much vanilla configuration.
I have org-download-method
set to attach
, as I prefer using org's attachment machinery. This works fine with images, but does not behave as expected with non-image files.
From a fresh restart of emacs, if I drag a non-image file into an org buffer:
- the file is put into my
~/Org
folder rather than as a subdirectory as~/Org/.attach
as expected - there is an error that
org-attach-dir
as a function is void - no link is created due to this error
If I drag an image:
- The file is put into the
~/Org/.attach
hierarchy as expected - A link is correctly created
If I drag a non-image after having dragged an image:
- The file is still incorrectly put into
~/Org
- A link is created, but it is something like
attachment:../../../filename.ext
@jlmaccal Thanks. It should now no longer complain about org-attach-dir
function.
I tested and it creates links like this:
#+DOWNLOADED: https://arxiv.org/pdf/2005.02353 @ 2020-05-06 20:26:52
[[attachment:2020-05-06_20-26-52_2005.02353.pdf]]
It's a different link syntax from what I'm used to, but it still works.
@abo-abo It's still not working for me for some reason.
When I drag a pdf file onto an org buffer, what I expect to happen is:
- an ID is associated with the current heading
- the dropped file is written to a subdirectory of
~/Org/.attach
depending on the ID - An
attachment:filename.ext
link is created
What happens now is:
- no ID is created
- the file is written directly to
~/Org/.attach
rather than a subdirectory - the link has the form
attachment:.attach/filename.ext
As far as I can tell, with an image, the org-attach
machinery is being used to write the file. This doesn't seem to be the case with non-image files. I'm new to the intricacies of org
/org-attach
/org-download
so I'm having a bit of hard time understanding how it all fits together.
I'm realizing now that doom is trying to handle non-image files itself. I think the problem lies there, rather than in org-download
.