Re: PATCH II (for testing only): [Bug, Debian(?)] "g" goes not

[Kevin Greiner <kgreiner@xpediantsolutions.com>]

Mark Plaksin <happy@mcplaksin.org> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> Mark Plaksin <happy@mcplaksin.org> writes:
>>
>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>
>>>> Mark Plaksin <happy@mcplaksin.org> writes:
>>>>
>>>>> Marcus Frings <iam-est-hora-surgere@despammed.com> writes:
>>>>>
>>>>>> By the way, this is also a bug on my FreeBSD system. Both on Debian and
>>>>>> FreeBSD I use GNU Emacs 21.3.1 (and `g' fails on all systems) but on two
>>>>>> different Windoze boxes I use a CVS Emacs (and there `g' works without
>>>>>> any problems). So the new code seems to work for CVS Emacs but fails on
>>>>>> the current stable Emacs. Can this really be Emacs-specific?
>>>>>
>>>>> I have the problem with both CVS Emacs and the wonderful multi-tty
>>>>> (http://lorentey.web.elte.hu/project/emacs.html) Emacs which is CVS
>>>>> Emacs plus patches.
>>>>
>>>> This patch should be applied to rev 7.8 (CVS head) of gnus-start.el.
>>>> Please let me know what the outcome is.  Finally, if this doesn't
>>>> help, please revert to CVS head.
>>>
>>> Thanks for the patch!
>>>
>>> It doesn't change the behavior for me.  Testing this I was also
>>> reminded that the problem affects my nnvirtual groups too.
>>>
>>> After patching, I exited Emacs, started up again, started Gnus (which
>>> automatically checks groups at level 1), and then did 5 G.  Gnus
>>> checked all groups at level 4 and below but no groups at level 5.  I
>>> have both nnimap and nnvirtual groups at level 5.  As before, going to
>>> the top topic and hitting ESC g (i.e., ESC < ESC g) checks all groups at
>>> all levels.
>>
>> Well, I tried being a little smarter and did learn one fact.  The code
>> that Lars patched in gnus-start and that I re-patched in my previous
>> patch is never used when you do ESC < ESC g as you described.
>>
>> That would appear to indicate that your problems are being caused by
>> the rather innocuous addition of two inline declarations in gnus.el.
>> If so, the problem is more of an emacs bug that gnus, which would help
>> explain why it is only seen on certain platforms.
>>
>> All right, enough talk.  Here's the patch for gnus.el.  As before,
>> apply it to the current revision of gnus.el.  What is different is
>> that you MUST delete all *.elc files before compiling gnus.  The
>> reason is that gnus-secondary-method-p is an inline function (a
>> defsubst) which, like a macro, is expanded at compilation time.
>
> Same results with this patch.  Can I provide more information or help
> in some other way?

Definitely.  I'll admit that right now, I'm skeptical that unpatching
Lars code change actually fixes this problem.

So, let's go back to the beginning.  The problem as I understand is
that your nnimap, nnvirtual, perhaps other, groups are not fetching
new articles.  As an example, the command 'ESC < ESC g' was provided.

ESC < is move point OK
ESC g gnus-topic-get-new-news-this-topic

gnus-topic-get-new-news-this-topic is a fairly simple function that
selects a set of groups then calls gnus-group-get-new-news-this-group.
Hmmm.  That's identical to turning off the topic mode, marking several
groups with '#', then pressing 'ESC g'.  Does this work for you or is
it also broken?  (This will determine whether the problem is in selecting
or processing the groups).

Assuming that it is still broken...

gnus-group-get-new-news-this-group loops over each group
calling... gnus-activate-group then, if it returned non-nil,
gnus-get-unread-articles-in-group appears to be the workhorse.

This is interesting... gnus-get-unread-articles-in-group does NOTHING
if (gnus-active group) returns nil.

So, here's the next test.  In your group buffer, type

M-: (gnus-activate-group "GROUP")<RET> {where GROUP is the group name
                        as shown in the group buffer.  Obviously pick
                        a group that is not updating.}

What does this function return in the minibuffer?  If it is nil, your
group isn't activating.

If it returned a cons, something like (2 . 1000), activation was
successful.

If the group activated, try this:

M-: (gnus-active "GROUP")<RET> {where GROUP is the same group as before}

Did you get the same cons or nil?

OK, last chance with the easy stuff.  Set both gnus-use-cache and
gnus-agent to nil.  Fetch new news again.  Does this fix the problem?

If you haven't seen any nil values by now, you're probably best off
debugging the gnus-get-unread-articles-in-group function.  Don't
bother stepping into the backend functions until certain that it will
be necessary.  That is, step over the gnus-request-update-info and
gnus-activate-group calls, until you have verified that
gnus-get-unread-articles-in-group does the right thing with the given
active range and list of read articles.

Kevin