`url-retrieve-synchronously' is not synchronous enough

`url-retrieve-synchronously' is not synchronous enough

[Eduardo Ochs]

`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.

My version of Emacs is:
(emacs-version) ->
"GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2007-11-09 on persephone".


Cheers,
  Eduardo Ochs
  eduardoochs@gmail.com
  http://angg.twu.net/

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.

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

[Eduardo Ochs]

> > `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.
>
> 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.

That fixed it! Thanks. :-)

  Eduardo Ochs
  http://angg.twu.net/
  eduardoochs@gmail.com