Re: [O] Drag images from Firefox to org-mode

[Oleh]

Thanks for the feedback, Rick.

I strongly disagree, for a couple of reasons:

- Esp. on non-unix systems, the contents of the cut-buffer are not
  necessarily the same as the contents of the system clipboard. This
  is the problem I was having w/ your code on windows, where the
  cut-buffer contained the value of the current (or possibly last)
  selection, but the clipboard had a url.

This can be fixed with a platform-aware function that checks both the clipboard and the cut-buffer.

 

- It is certainly possible to type in a url

URL to a site - maybe (still, probably 90% of people will copy it), but

an image where the relative path is just gibberish - certainly not.

And the point is that the clipboard is resorted to when drag-and-drop fails,

i.e. the image is a link and we want the link to the image, not the link itself.

At that point, to get the address of the image, the user either clicks "Copy Image Location" or "View Image". With "View Image" there's an extra step of copying the URL from the address bar.

At this point, when URL is surely in the clipboard, so extra yanking and confirming is just red tape.

 

- You might want to DND a url from another buffer.

No problem - M-w in one buffer, and `org-download-image' in the other.

 

- It is ergonomically wrong for an interactive function defined to
  take an argument (and called "download-image") to automagically use a
  value from somewhere else and not actually take an argument.

A new function with name `org-download-yank' can be added, no problem. And Emacs is automagical by nature: I don't know why C-s C-w makes sense, but I love it.

 

It would however, make sense for the function to use the current
clipboard contents if called with a prefix.

A customizable option can be added to configure this behavior.

 

In the same vein, I was thinking about the automagically creating a
subdirectory based on a top level heading. This is also wrong for a
couple reasons:

- Creating a potentially =very long directory name with spaces= can
  cause multiple problems, both on unix and esp. non-unix systems,
  where spaces may not be allowed in directory names, or there may be
  limits on filename/directory length.

 This can be fixed by adding `org-download-max-filename-length`. When it 

overflows, just resort to `default-directory' and provide a message/option to fix.

By the way, which system doesn't allow for spaces in directory names?

- The use of the top-level heading is arbitrary and may have nothing
  to do with the current context (for instance, i sometimes group
  together multiple documents to be output w/ export subtree in the
  same master document)

Can be configured with a different function name / file-local variable. 

I just think that sorting inline links by headings for some level (not 

necessarily top-level, configuration should be added) is a useful idea.

My use case is figures for weekly assignments for an online course:

each week has a top-level heading: all movies and slides go there, as 

well as the figures for the assignments. I wouldn't want 15 weeks worth 

of figures to be stored in one dir.

 

The default should be to save it in the same directory as the document
(which by the way, may not be in emacs's idea of the current
directory). Also, the filename should not be expanded to an absolute
path, which makes the document non-portable and will break publishing.

This is a very good remark.

 

If you want the ability to create arbitrary output directories based
on document context, the customization can be made to accept a
function (lambda) as a value, which could then return a directory
prefix.

This isn't an option for users with no elisp skills. Customization is a 

nice way to show what kind of things can be done. And when a user

requires just a bit more tweaking after the customization, she can ask on

the list.

While i realize the current implementation meets your needs, if the
code is to be included in the org-mode distribution it should follow
emacs and org conventions and not contains any suprises.

I agree of course. It's still work in progress. 

I would be glad to make the above changes on tuesday when i get back
to the office. Please send me (again) the url of the github repos with
the current set of changes and I will update it so that it will allow
the current functionality but have less magical default behavior.

The repo is at https://github.com/abo-abo/org-download.

I'll probably add some fixes and functionality in the meantime.

regards,

Oleh