Bastien writes: > Hi, > > stardiviner writes: > >> I found when network is bad and slow, or the download file is big, the >> org-attach-url will suspend Emacs for a long time. User might have to cancel >> downloading, and start again later. > > Indeed, this might be annoying. At the same time, it is not > unreasonable to expect the user to know what size is the contents he > is willing to attach to an Org node. It's not the URL file size problem, sometime network is bad. I meet some situations like downloading 1M file might use 5 minutes. Not 1M file or 1G file difference. > >> I hope to make "org-attach-url" download file asynchronously. But function >> org-attach-attach hardcoded this function for 'url method. Here is a patch to >> make it into an option. > > (FWIW, I could not find the patch.) Aha, I forgot the patch. I attached now. The patch does not provide an async function to download. Just provide an easy way for user to use other async functions. > > I think you are on the right track when trying to enhance the 'url > package. Maybe url-copy-file should be asynchronous and url could > provide url-copy-file-synchronously (to mimic the url-retrieve and > url-retrieve-synchronously pair)? Actually I did check out url-copy-file-synchronously source code, try to mimic an async version function. But seems I can't implement it. I will post an email to Emacs-dev mailing list whether this can be improved. > > Until Emacs has a function to copy a URL's contents asynchronously, > I'd rather not add this functionality in Org. Emacs async functionality is always bad. Waiting for Emacs get better async support might need a very long time. I still think simply provide an simple entry for user to change downloading function is a simpler option. WDYT? -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3