(url-retrieve-synchronously): Work around the fact that

url-http sometimes doesn't call the callback.

diff --git a/lisp/url/ChangeLog b/lisp/url/ChangeLog
index 82b7f64dc010aece0632c84a6642a355e6756b11..a023bdf18c772ec1fcc9be9af6b0a2a1a6103ad9 100644 (file)
--- a/lisp/url/ChangeLog
+++ b/lisp/url/ChangeLog
@@ -1,3 +1,8 @@
+2005-04-18  Stefan Monnier  <monnier@iro.umontreal.ca>
+
+       * url.el (url-retrieve-synchronously): Work around the fact that
+       url-http sometimes doesn't call the callback.
+
 2005-04-04  Lute Kamstra  <lute@gnu.org>
 
        * url-handlers.el (url-handler-mode): Specify :group.

diff --git a/lisp/url/url.el b/lisp/url/url.el
index a9fd46bc23a69e167d410a962952829d67f9504f..05ef85c93004acd0b5a79fd59c5819ef09791972 100644 (file)
--- a/lisp/url/url.el
+++ b/lisp/url/url.el
@@ -180,15 +180,23 @@ no further processing).  URL is either a string or a parsed URL."
          (url-debug 'retrieval
                     "Spinning in url-retrieve-synchronously: %S (%S)"
                     retrieval-done asynch-buffer)
-         ;; We used to use `sit-for' here, but in some cases it wouldn't
-         ;; work because apparently pending keyboard input would always
-         ;; interrupt it before it got a chance to handle process input.
-         ;; `sleep-for' was tried but it lead to other forms of
-         ;; hanging.  --Stef
-         (unless (accept-process-output proc)
-           ;; accept-process-output returned nil, maybe because the process
-           ;; exited (and may have been replaced with another).
-           (setq proc (get-buffer-process asynch-buffer)))))
+         (if (memq (process-status proc) '(closed exit signal failed))
+             ;; 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
+             ;; url-http can then warn us that the download has completed.
+              ;; In the mean time, we use this here workaround.
+              (setq retrieval-done t)
+            ;; We used to use `sit-for' here, but in some cases it wouldn't
+            ;; work because apparently pending keyboard input would always
+            ;; interrupt it before it got a chance to handle process input.
+            ;; `sleep-for' was tried but it lead to other forms of
+            ;; hanging.  --Stef
+            (unless (accept-process-output proc)
+              ;; accept-process-output returned nil, maybe because the process
+              ;; exited (and may have been replaced with another).
+              (setq proc (get-buffer-process asynch-buffer))))))
       asynch-buffer)))
 
 (defun url-mm-callback (&rest ignored)