bug#71295: 29.3; url-retrieve-synchronously does not timeout if initial connection hangs

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 8 Jun 2024 00:32:44 +0300
> Cc: z@bcc32.com, 71295@debbugs.gnu.org, azeng@janestreet.com
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 07/06/2024 09:20, Eli Zaretskii wrote:
> >> Date: Thu, 6 Jun 2024 23:41:39 +0300
> >> Cc:71295@debbugs.gnu.org,azeng@janestreet.com
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >> It seems like a leaky abstraction (the caller has to be aware that what
> >> happens under the covers is done in several steps, and the timeout only
> >> applies to subsequent ones).
> >>
> >> If we could change the implementation to a more intuitive behavior, that
> >> would be a win, I think. Can somebody think of adverse effects?
> > Do you have a patch to consider?
> 
> This seems to work:
> 
> diff --git a/lisp/url/url.el b/lisp/url/url.el
> index dea251b453b..3b4021ceca8 100644
> --- a/lisp/url/url.el
> +++ b/lisp/url/url.el
> @@ -235,7 +235,7 @@ url-retrieve-synchronously
>   TIMEOUT is passed, it should be a number that says (in seconds)
>   how long to wait for a response before giving up."
>     (url-do-setup)
> -  (let* (url-asynchronous
> +  (let* ((url-asynchronous t)
>            data-buffer
>            (callback (lambda (&rest _args)
>                        (setq data-buffer (current-buffer))

Fine by me to install this on master, but please add there a comment
explaining why we do that disregarding the "synchronously" part of the
API's name.

Did you consider binding url-asynchronous non-nil only if TIMEOUT is
omitted or nil?  That could be even better, since the risk of breaking
something is lower, and OTOH if TIMEOUT is not passed, the original
problem does not exist and waiting "forever" is justified.  WDYT?