Re: url-retrieve may cause hang

[Richard Stallman <rms@gnu.org>]

    I made "status" an extra argument at the beginning of the argument
    list (so if CBARGS has N elements, the callback is called with N+1
    arguments).  I described this in the docstring of url-retrieve in my
    patch below (not yet committed).

Is this new argument _unconditionally_ present?
I can't tell, and I see comments that seem to suggest
that it might not be so:

+       (setf (car url-callback-arguments)
+ 	    (nconc (list :error (list 'error 'connection-failed why
+ 				      :host (url-host url-current-object)
+ 				      :service (url-port url-current-object)))
+ 		   (car url-callback-arguments)))

And this:

      It is called as (apply CALLBACK STATUS CBARGS), where STATUS
    ! is a list with an even number of elements representing what happened
    ! during the request, with most recent events first.  Each pair is one
    ! of:
    ! 
    ! \(:redirect REDIRECTED-TO) - the request was redirected to this URL
    ! \(:error (ERROR-SYMBOL . DATA)) - an error occurred.  The error can be
    ! signaled with (signal ERROR-SYMBOL DATA).

I don't like that variability, and it is easy to avoid.  If we are to
change the API of these callbacks now, let's change it to something
more consistent: add a single argument unconditionally.  That added
argument can be a property list in which :redirect and :error may
occur.