Re: Drag images from Firefox to org-mode

[Oleh <ohwoeowho@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4600 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 7386 bytes --]