Mercurial > emacs
changeset 68123:ba5077259cc1
(url-retrieve-synchronously): Adjust the workaround so as not
to stop in the middle of a redirection.
| author | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| date | Tue, 10 Jan 2006 19:31:15 +0000 |
| parents | b720282b1826 |
| children | 32fc565ba875 |
| files | lisp/url/ChangeLog lisp/url/url.el |
| diffstat | 2 files changed, 8 insertions(+), 2 deletions(-) [+] |
line wrap: on
line diff
--- 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>
--- 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)