Thank you for your comments! They are very helpful.
> Thanks for your patch. However, I wonder if we really want this. Remote
> images could be slow to fetch, and it would make buffer unusable.
I personally needed this functionality. I have tried to reduce the amount of time spent on fetching the images by checking whether the images have been fetched before and whether the remote files are newer. Yes these communications take time as it should be expected if one opens an org file remotely (therefore connection should have been made) or when one specifies a remote image as path and wants to display it inline.
Perhaps I could add an option flag or ask a question before fetching for user to decide whether to display remote images or not? In case the behaviour of displaying remote images inline is not desired? One scenario I can think of is that `org-startup-with-inline-images' is set to true and the file is sometimes visited remotely.
Any opinion or comment on this, please?
>> - (let ((file (expand-file-name (org-element-property :path link))))
>> + (let ((file (substitute-in-file-name (expand-file-name (org-element-property :path link)))))
> Why is it needed?
Because the file path for a remote file, as far as I have tested, have redundant slashes "/" at the beginning of the path which makes org-file-remote-p to return nil for a remote path.
`substitute-in-file-name' corrects such path. `substitute-in-file-name' is also used in `org-open-file'. So I followed suit.
> Are you sure the return value (a boolean, i.e., not necessarily
> a string) should belong to the `concat'?
Good point. I changed the code (see below, and attached).
> (create-image (if (org-file-remote-p file) ...)
> (and width 'imagemagick)
> :width width)
I agree. Thanks. I made the code cleaner now (see below, and attached).