Re: Aget woes in oort gnus

Re: Aget woes in oort gnus

[Kinkie]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

[...]

>>>> - with 0.15 I had this problem where despite being started as
>>>> gnus-unplugged, it complained that it couldn't select my
>>>> gnus-select-method server at startup. Having it denied, going to the
>>>> server buffer, re-enabling it and gnus-group-get-new-news'ing would
>>>> allow me to see the groups from that server. I'm not sure this is
>>>> still true (I've just updated).
>>>
>>> Pls retest.  This should have been fixed in revision 6.151.
>>
>> Gnus behaved as I described in the run I'm writing this article with,
>> which is today's CVS HEAD.
>>
> OK, two out of three isn't bad.
>
> BTW, expiration can be painfully slow.  I just checked in a couple of
> very minor changes that should make it a little faster.

It's OK for me. I only follow 30something groups, not more than 1k
articles/day.

> I've been unable to reproduce the last error.  However, it sounds like
> your gnus-select-method server is no longer agentized.  I'd like you
> to check this by opening the server buffer ('^' in the group buffer).
> Your gnus-select-method server should display '(agent)' on the line
> next to its name.  If it does not, we've found the problem.  You can
> agentize that server by moving point to its name then typing 'J a'.

Already checked. It's agentized. Tried toggling it off and on, but no
changes.

-- 
	kinkie (kinkie-ml [at] tiscalinet [dot] it)
	Random fortune, unrelated to the message:
Virtue is a relative term.
		-- Spock, "Friday's Child", stardate 3499.1

Re: Aget woes in oort gnus

[Kinkie]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

>>>>>>>> - with 0.15 I had this problem where despite being started as
>>>>>>>> gnus-unplugged, it complained that it couldn't select my
>>>>>>>> gnus-select-method server at startup. Having it denied, going
>>>>>>>> to the server buffer, re-enabling it and
>>>>>>>> gnus-group-get-new-news'ing would allow me to see the groups
>>>>>>>> from that server. I'm not sure this is still true (I've just
>>>>>>>> updated).
>>>>>>>
>>>
>>> Check the value of gnus-server-unopen-status.  It needs to be
>>> either nil or offline.
>>
>> In a freshly started gnus, after accepting to continue after the
>> failure but before doing anything else, it's nil.
>
> OK, it looks like we'll be doing this one the hard way.
>
> Please do the following in a freshly started emacs.
> 1) M-: (setq gnus-verbose 10)
> 2) M-x gnus-unplugged
>
> Do whatever you usually do to get the group buffer to appear then
> stop.  What I'd like to see is the contents of your message buffer.
> I'm hoping to use the message text to trace the execution path.  If
> this doesn't work, I'll probably have to send a patched file with
> custom instrumentation in it.

I didn't get the trace, but MAYBE I understood the problem. It looks
like a problem of crossed wires.

I have a few servers in my gnus: two nntp servers (including
gnus-select-method), a couple of nnfolders and an nnimap which I
really don't use. Only the nntp servers are agentized. It appears that
if I start gnus up when not-connected, for some reason it misunderstands
the failure to open the nnimap as problems with the select-method
server. If I'm online when I fire up gnus, then no errors occur. I've
disabled the nnimap server, and everything appears to be working fine.

-- 
	kinkie (kinkie-ml [at] tiscalinet [dot] it)
	Random fortune, unrelated to the message:
The meek shall inherit the earth, but *not* its mineral rights.
		-- J.P. Getty