bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside eldoc-documentation-function

[Eli Zaretskii]

> Cc: 34763@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 12 Mar 2019 19:44:04 +0200
> 
> > Crystal ball says there _was_ in fact a change: the error message text
> > has changed slightly.
> 
> I'm sorry, you are right. The text did change.

It's similar enough, so I can understand the confusion and
disappointment ;-).

> > The below should fix both; please see if it does, and also whether it
> > fixes your original real-life use case.
> 
> The patch does away with the first part of the complaint: no "Transfer 
> interrupted" or "Interrupted" messages anymore. Thanks!
> 
> The HTTP requests do take longer and longer times to complete, though. 
> After enough typing, the 10th request never seems to complete. I can 
> monitor that with changing the function's definition to
> 
> (defun silly-eldoc ()
>    (dotimes (i 10)
>      (url-retrieve-synchronously "http://www.google.com";)
>      (message "try %i" i))
>    "done")
> 
> and watching the Messages buffer.
> 
> The counter fairly quickly reaches 0, but rarely goes past 3, and almost 
> never past 5 (now that I've been calling that eldoc function for several 
> minutes, albeit with big pauses).
> 
> M-x list-processes shows 12 lines with very similar contents.
> 
> I don't know whether having 10 requests to the same URL counts as a 
> real-life case, though.

Isn't the above expected, given the recipe?  You are initiating an
HTTP retrieval inside while-no-input, and then provide input which
aborts the retrieval.  What else can we expect from this code?

The point of my changes was to avoid signaling errors from the
retrieval routines when some other unrelated code, such as the "real"
eldoc function, is running inside while-no-input.  But if you run
url-retrieve-synchronously itself inside while-no-input, you should
expect it to be aborted by arriving input, right?  Or am I missing
something?