Re: Gnus fetch freezes emacs

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Mon, 03 Jul 2023 09:36:26 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>
>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>>
>>> On Sunday,  2 Jul 2023 at 16:59, Eric Abrahamsen wrote:
>>>> If everyone's hitting this with NNTP servers, you can set
>>>> `nntp-connection-timeout' to a number of seconds. It is nil by default,
>>>> which I guess would result in permanent hangs.
>
> Is this variable supposed to be set in the value of gnus-select-method?
> For example, like this:
>
> (setq gnus-select-method '(nntp "news.gmane.io"
> 				(nntp-connection-timeout 3)))

It's a defvoo, so it can either be set globally, or as a server
parameter.

>>> So this works, in the sense that it stops me waiting forever... However,
>>> it seems (early days yet) that when it fails to open the connection to
>>> an NNTP server, it stops retrieving news and I have to hit 'g' again to
>>> get the counts etc. updated for other servers. [...]
>
> That sounds basically like what the function I'm using in place of
> gnus-group-get-new-news (see my first post in this thread) does.  Could
> such a function take effect if added to one of the server hook variables
> nntp-server-opened-hook, nntp-server-action-alist or
> nntp-open-connection-function?  From the descriptions in the manual it
> isn't clear to me.  Or is there some better Gnus hook variable for this
> purpose?  If not could one be added?

I'm not sure what function you mean. Eric F is just describing the
unfortunate behavior of nntp-connection-timeout, which interrupts the
entire fetching process when it hits the timeout.

>> Yeah, I'd put in a dumb fix for this that turned out to be buggy, so we
>> just recently reverted it. I have a more thorough fix in progress
>> somewhere here, that would report a server connection failure without
>> interrupting the rest of the servers, but it's not done yet. I've had
>> very little time for coding recently, but will get to it At Some Point.
>>
>> Glad it's at least better than it was. I wonder if we should have some
>> generous timeout set by default...
>
> It might make sense to continue this discussion in bug#52735.

This doesn't seem like the same issue -- this problem is pretty well
understood.

Eric