# HG changeset patch
# User Stefan Monnier <monnier@iro.umontreal.ca>
# Date 1136921475 0
# Node ID ba5077259cc168a4cc536521e6d4d00c2b2fc6c1
# Parent  b720282b18260f5b9ae7bb07eb0ffb906a8e0236
(url-retrieve-synchronously): Adjust the workaround so as not
to stop in the middle of a redirection.

diff -r b720282b1826 -r ba5077259cc1 lisp/url/ChangeLog
--- a/lisp/url/ChangeLog	Tue Jan 10 19:16:02 2006 +0000
+++ b/lisp/url/ChangeLog	Tue Jan 10 19:31:15 2006 +0000
@@ -1,5 +1,8 @@
 2006-01-10  Stefan Monnier  <monnier@iro.umontreal.ca>
 
+	* 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  <monnier@iro.umontreal.ca>
diff -r b720282b1826 -r ba5077259cc1 lisp/url/url.el
--- a/lisp/url/url.el	Tue Jan 10 19:16:02 2006 +0000
+++ b/lisp/url/url.el	Tue Jan 10 19:31:15 2006 +0000
@@ -190,11 +190,14 @@
 		     "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)