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

[Dmitry Gutov <dmitry@gutov.dev>]

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.