From e7ea7cac4eb8934dfcb53457ac7af0f70ec7d136 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Tue, 10 Jan 2006 19:31:15 +0000 Subject: [PATCH] (url-retrieve-synchronously): Adjust the workaround so as not to stop in the middle of a redirection. --- lisp/url/ChangeLog | 3 +++ lisp/url/url.el | 7 +++++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/lisp/url/ChangeLog b/lisp/url/ChangeLog index 08d5eb4c6bf..56d1faaa84d 100644 --- a/lisp/url/ChangeLog +++ b/lisp/url/ChangeLog @@ -1,5 +1,8 @@ 2006-01-10 Stefan Monnier + * url.el (url-retrieve-synchronously): Adjust the workaround so as not + to stop in the middle of a redirection. + * url-vars.el (url-privacy-level): Add setter. 2006-01-05 Stefan Monnier diff --git a/lisp/url/url.el b/lisp/url/url.el index f9d06010171..10c449cb30b 100644 --- a/lisp/url/url.el +++ b/lisp/url/url.el @@ -190,11 +190,14 @@ no further processing). URL is either a string or a parsed URL." "Spinning in url-retrieve-synchronously: %S (%S)" retrieval-done asynch-buffer) (if (and proc (memq (process-status proc) - '(closed exit signal failed))) + '(closed exit signal failed)) + ;; Make sure another process hasn't been started, as can + ;; happen with http redirections. + (eq proc (or (get-buffer-process asynch-buffer) proc))) ;; FIXME: It's not clear whether url-retrieve's callback is ;; guaranteed to be called or not. It seems that url-http ;; decides sometimes consciously not to call it, so it's not - ;; clear that it's a bug, but even if we need to decide how + ;; clear that it's a bug, but even then we need to decide how ;; url-http can then warn us that the download has completed. ;; In the mean time, we use this here workaround. (setq retrieval-done t) -- 2.39.2