Re: `url-retrieve-synchronously' is not synchronous enough

[Richard Stallman]

    `url-retrieve-synchronously' is not synchronous enough.
    When I execute this sexp,

    (progn (switch-to-buffer
            (url-retrieve-synchronously "http://127.0.0.1/";))
           (point))

    the result is (point-max), but when I get the control back the
    point is at the first character of a buffer - as if some hook
    containing (goto-char (point-min)) ran after the (point) in the
    progn.

I think I see the cause of this.    In url-retrieve-synchronously:

        (while (not retrieval-done)
          (url-debug 'retrieval
                     "Spinning in url-retrieve-synchronously: %S (%S)"
                     retrieval-done asynch-buffer)
          (if (buffer-local-value 'url-redirect-buffer asynch-buffer)
              (setq proc (get-buffer-process
                          (setq asynch-buffer
                                (buffer-local-value 'url-redirect-buffer
                                                    asynch-buffer))))
            (if (and proc (memq (process-status proc)
                                '(closed exit signal failed))

if the process terminated recently, process-status can update the
process status to `exit', or the connection status to `closed', but it
can't run the sentinel.  That happens only when Emacs becomes idle.

Does this patch make it work?

*** url.el      25 Jul 2007 11:49:25 -0400      1.27.2.1
--- url.el      10 Nov 2007 19:58:50 -0500      
***************
*** 240,246 ****
                ;; XXX: The callback must always be called.  Any
                ;; exception is a bug that should be fixed, not worked
                ;; around.
!                 (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.
--- 240,248 ----
                ;; XXX: The callback must always be called.  Any
                ;; exception is a bug that should be fixed, not worked
                ;; around.
!               (progn ;; Call delete-process so we run any sentinel now.
!                 (delete-process proc)
!                 (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.