Kit-Yan Choi <k...@kychoi.org> writes: >> 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?
I recently worked with remote pictures for html-slides. The slides were stored on my github powered website, and the pictures were hosted on my owncloud. So I definitely see the merits of Kit-Yan's proposal. Also, remote files will work in HTML, but not in latex or odt (I think), so local caching could maybe also be applied, optionally, when exporting documents. org-startup-with-inline-images should have an equivalent file-variable that takes priority, and probably org-startup-with-inline-images should default to nil. The above is of course "IMO". —Rasmus -- Got mashed potatoes. Ain't got no T-Bone. No T-Bone
