Stefan Monnier <[EMAIL PROTECTED]> writes: >> The more I think about it the more my patch seems like an OK fix instead of >> a workaround. What makes it a workaround to you? > > There's still some fundamental problems with the code: url-retrieve returns > a buffer which is expected to be the buffer into which the result will be > put (and where ther callback will be executed), but after a redirect, the > data is actually put into yet another buffer. I suspect a good fix will > require some change to the "API" (BTW other fixes to the API may be needed to > really fix the problem related to callbacks that don't get called, as > mentioned in comments in url-retrieve-synchronously).
Gotcha. This level of analysis of the URL library is beyond me (for now anyhow :) >> My fix is short and simple and preserves the synchronicity of the original >> call. That is, if url-retrieve encountered the redirect, it will remain >> asynchronous; if url-retrieve-synchronously encountered the redirect it >> remains synchronous. > > Hmmm it seemed to me that your patch causes a redirect in url-retrieve to > make the end of the operation synchronous rather than asynchronous. > I'll have to take another look. Maybe I wasn't clear enough. The redirect is always handled synchronously but that doesn't change the synchronicity of the original url-retrieve* call. If you call url-retrieve and there's a redirect, the original url-retrieve call will remain asynchronous. If you call url-retrieve-synchronously and there's a redirect, the original call will remain synchronous. _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
