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

[Dmitry Gutov]

On 08/06/2024 09:08, Eli Zaretskii wrote:

> > 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?

That's a good idea. Pushed to master, with this addition and a comment.

Thinking further, though, our ability to do so bring the existence of 
this variable into question (we only change it in 
url-retrieve-synchronously).

I see it's been added as part of bug#26835 resolution, so maybe we'll 
need to re-examine that fix.