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

[Dmitry Gutov]

On 12.03.2019 19:18, Eli Zaretskii wrote:
> > Cc: 34763@debbugs.gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Tue, 12 Mar 2019 11:08:06 +0200
> >
> > On 11.03.2019 16:30, Eli Zaretskii wrote:
> >
> > > Does it help to replace this:
> > >
> > >     (defsubst url-http-debug (&rest args)
> > >       (if quit-flag
> > >
> > > with this:
> > >
> > >     (defsubst url-http-debug (&rest args)
> > >       (if (eq quit-flag t)
> > >
> > > in url-http.el?
> >
> > No change, unfortunately. I double-checked.
>
> 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.

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