bug in gnus-fixup-nnimap-unread-after-getting-new-news?

bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Ted Zlatanov]

When the function gnus-fixup-nnimap-unread-after-getting-new-news gets
run by the gnus-after-getting-new-news-hook, the unread counts are
wrong for me.  For instance, "spam" (nnml backend) will get the same
amount of unread messages as "nnimap+mail.lifelogs.com:mail" (nnimap
backend).  Looking at the
gnus-fixup-nnimap-unread-after-getting-new-news function, it appears
to me that it uses the mailbox name as known to nnimap internally,
which would only be correct if the nnimap server was the primary
server.

Furthermore, the function seems to use nnimap-mailbox-info, which is
applicable only to the current IMAP server, so probably there will be
issues with multiple IMAP servers as well.  Please let me know if I'm
mistaken about this, so I can look elsewhere.

Thanks
Ted

Re: bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> When the function gnus-fixup-nnimap-unread-after-getting-new-news gets
> run by the gnus-after-getting-new-news-hook, the unread counts are
> wrong for me.  For instance, "spam" (nnml backend) will get the same
> amount of unread messages as "nnimap+mail.lifelogs.com:mail" (nnimap
> backend).  Looking at the
> gnus-fixup-nnimap-unread-after-getting-new-news function, it appears
> to me that it uses the mailbox name as known to nnimap internally,
> which would only be correct if the nnimap server was the primary
> server.
>
> Furthermore, the function seems to use nnimap-mailbox-info, which is
> applicable only to the current IMAP server, so probably there will be
> issues with multiple IMAP servers as well.  Please let me know if I'm
> mistaken about this, so I can look elsewhere.

I think you are right.  Maybe it is time to implement Kai's suggestion
of a new backend API to support this function properly?

Re: bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Ted Zlatanov]

On Sat, 24 May 2003, jas@extundo.com wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> When the function gnus-fixup-nnimap-unread-after-getting-new-news
>> gets run by the gnus-after-getting-new-news-hook, the unread counts
>> are wrong for me.  For instance, "spam" (nnml backend) will get the
>> same amount of unread messages as "nnimap+mail.lifelogs.com:mail"
>> (nnimap backend).  Looking at the
>> gnus-fixup-nnimap-unread-after-getting-new-news function, it
>> appears to me that it uses the mailbox name as known to nnimap
>> internally, which would only be correct if the nnimap server was
>> the primary server.
>>
>> Furthermore, the function seems to use nnimap-mailbox-info, which
>> is applicable only to the current IMAP server, so probably there
>> will be issues with multiple IMAP servers as well.  Please let me
>> know if I'm mistaken about this, so I can look elsewhere.
> 
> I think you are right.  Maybe it is time to implement Kai's
> suggestion of a new backend API to support this function properly?

I'll help if I can, I don't know the backend APIs that well though.

In the meanwhile, should we disable
gnus-fixup-nnimap-unread-after-getting-new-news?  I'm currently
defaliasing it to 'ignore, but others may be seeing the same bug.  I
have not seen any bad effects from disabling it in my setup.

Ted

Re: bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sat, 24 May 2003, jas@extundo.com wrote:
>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> 
>>> When the function gnus-fixup-nnimap-unread-after-getting-new-news
>>> gets run by the gnus-after-getting-new-news-hook, the unread counts
>>> are wrong for me.  For instance, "spam" (nnml backend) will get the
>>> same amount of unread messages as "nnimap+mail.lifelogs.com:mail"
>>> (nnimap backend).  Looking at the
>>> gnus-fixup-nnimap-unread-after-getting-new-news function, it
>>> appears to me that it uses the mailbox name as known to nnimap
>>> internally, which would only be correct if the nnimap server was
>>> the primary server.
>>>
>>> Furthermore, the function seems to use nnimap-mailbox-info, which
>>> is applicable only to the current IMAP server, so probably there
>>> will be issues with multiple IMAP servers as well.  Please let me
>>> know if I'm mistaken about this, so I can look elsewhere.
>> 
>> I think you are right.  Maybe it is time to implement Kai's
>> suggestion of a new backend API to support this function properly?
>
> I'll help if I can, I don't know the backend APIs that well though.
>
> In the meanwhile, should we disable
> gnus-fixup-nnimap-unread-after-getting-new-news?  I'm currently
> defaliasing it to 'ignore, but others may be seeing the same bug.  I
> have not seen any bad effects from disabling it in my setup.

Looking closer at the problem, I see that at least my
nnimap-mailbox-info contains fully qualified group names.  So I don't
see how it would fail, it iterates over all fully qualified names and
update the info for each of those groups.  Perhaps you could edebug
the function to see where and why it overwrites non-nnimap group info?
What's your value of nnimap-mailbox-info?

Re: bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Ted Zlatanov]

On Sat, 24 May 2003, jas@extundo.com wrote:
> Looking closer at the problem, I see that at least my
> nnimap-mailbox-info contains fully qualified group names.  So I
> don't see how it would fail, it iterates over all fully qualified
> names and update the info for each of those groups.  Perhaps you
> could edebug the function to see where and why it overwrites
> non-nnimap group info?  What's your value of nnimap-mailbox-info?

I read my mail on two machines, one of them has nnimap-mailbox-info as 

(machine A)

[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
nnimap+mail\.lifelogs\.com:ding\.archive ....]

and the other as 

(machine B)

[0 0 ding\.archive lifelogs 0 0 0 0 0 0 0 0 0 ....]

On both machines nnimap is secondary:

(A) gnus-secondary-select-methods's value is 
((nnimap "mail.lifelogs.com"))

(B) gnus-secondary-select-methods's value is 
((nnimap "mail.lifelogs.com"))

So machine A is somehow misbehaving.  I'll look at the problem when I
get to work, where A is.  A and B are *very* similar in configuration,
though.

Ted

Re: bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Ted Zlatanov]

On Sun, 25 May 2003, tzz@lifelogs.com wrote:
> On Sat, 24 May 2003, jas@extundo.com wrote:
>> Looking closer at the problem, I see that at least my
>> nnimap-mailbox-info contains fully qualified group names.  So I
>> don't see how it would fail, it iterates over all fully qualified
>> names and update the info for each of those groups.  Perhaps you
>> could edebug the function to see where and why it overwrites
>> non-nnimap group info?  What's your value of nnimap-mailbox-info?
> 
> I read my mail on two machines, one of them has nnimap-mailbox-info
> as
> 
> (machine A)
> 
> [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> nnimap+mail\.lifelogs\.com:ding\.archive ....]
> 
> and the other as 
> 
> (machine B)
> 
> [0 0 ding\.archive lifelogs 0 0 0 0 0 0 0 0 0 ....]
> 
> On both machines nnimap is secondary:
> 
> (A) gnus-secondary-select-methods's value is 
> ((nnimap "mail.lifelogs.com"))
> 
> (B) gnus-secondary-select-methods's value is 
> ((nnimap "mail.lifelogs.com"))
> 
> So machine A is somehow misbehaving.  I'll look at the problem when
> I get to work, where A is.  A and B are *very* similar in
> configuration, though.

I thought the problem might have been with Emacs versions, but alas...

- A and B have Emacs 21.3

- CVS Gnus, updated at the same time

- exact same startup files, Gnus options, and Emacs libraries with
  small unrelated variations in .gnus.el based on the host name

- A is Solaris, B is Linux

Let me know where to look next to find where the short group names are
getting generated...

Thanks
Ted

Re: bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

>> I read my mail on two machines, one of them has nnimap-mailbox-info
>> as
>> 
>> (machine A)
>> 
>> [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> nnimap+mail\.lifelogs\.com:ding\.archive ....]
>> 
>> and the other as 
>> 
>> (machine B)
>> 
>> [0 0 ding\.archive lifelogs 0 0 0 0 0 0 0 0 0 ....]
>> 
>> On both machines nnimap is secondary:
>> 
>> (A) gnus-secondary-select-methods's value is 
>> ((nnimap "mail.lifelogs.com"))
>> 
>> (B) gnus-secondary-select-methods's value is 
>> ((nnimap "mail.lifelogs.com"))
>> 
>> So machine A is somehow misbehaving.  I'll look at the problem when
>> I get to work, where A is.  A and B are *very* similar in
>> configuration, though.
>
> I thought the problem might have been with Emacs versions, but alas...
>
> - A and B have Emacs 21.3
>
> - CVS Gnus, updated at the same time
>
> - exact same startup files, Gnus options, and Emacs libraries with
>   small unrelated variations in .gnus.el based on the host name
>
> - A is Solaris, B is Linux
>
> Let me know where to look next to find where the short group names are
> getting generated...

If you G e some nnimap groups, does it look the same on both machines?

Re: bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Ted Zlatanov]

On Wed, 28 May 2003, jas@extundo.com wrote:
> If you G e some nnimap groups, does it look the same on both
> machines?

Yes, "nnimap:mail.lifelogs.com" is the select method on both my home
and work machines for my "nnimap+mail.lifelogs.com:mail" group.

Thanks
Ted

Re: bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 28 May 2003, jas@extundo.com wrote:
>> If you G e some nnimap groups, does it look the same on both
>> machines?
>
> Yes, "nnimap:mail.lifelogs.com" is the select method on both my home
> and work machines for my "nnimap+mail.lifelogs.com:mail" group.

What does (gnus-group-prefixed-name "mail" "nnimap:mail.lifelogs.com")
evaluate to on both machines?  If they differ, try to find out why.

Re: bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Ted Zlatanov]

On Thu, 29 May 2003, jas@extundo.com wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> On Wed, 28 May 2003, jas@extundo.com wrote:
>>> If you G e some nnimap groups, does it look the same on both
>>> machines?
>>
>> Yes, "nnimap:mail.lifelogs.com" is the select method on both my
>> home and work machines for my "nnimap+mail.lifelogs.com:mail"
>> group.
> 
> What does (gnus-group-prefixed-name "mail"
> "nnimap:mail.lifelogs.com") evaluate to on both machines?  If they
> differ, try to find out why.

Same thing on both machines, "nnimap+mail.lifelogs.com:mail"

Ted

Re: bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 29 May 2003, jas@extundo.com wrote:
>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> 
>>> On Wed, 28 May 2003, jas@extundo.com wrote:
>>>> If you G e some nnimap groups, does it look the same on both
>>>> machines?
>>>
>>> Yes, "nnimap:mail.lifelogs.com" is the select method on both my
>>> home and work machines for my "nnimap+mail.lifelogs.com:mail"
>>> group.
>> 
>> What does (gnus-group-prefixed-name "mail"
>> "nnimap:mail.lifelogs.com") evaluate to on both machines?  If they
>> differ, try to find out why.
>
> Same thing on both machines, "nnimap+mail.lifelogs.com:mail"

Weird.  Could you try edebugging (or similar) nnimap-update-unseen to
see why gnus-group-prefixed-name returns unqualified group names on
one of the machines?  I don't understand how nnimap-mailbox-info could
end up containing unqualified group names unless g-g-p-n fail somehow.

Re: bug in gnus-fixup-nnimap-unread-after-getting-new-news?

[Ted Zlatanov]

On Fri, 30 May 2003, jas@extundo.com wrote:
> Weird.  Could you try edebugging (or similar) nnimap-update-unseen to
> see why gnus-group-prefixed-name returns unqualified group names on
> one of the machines?  I don't understand how nnimap-mailbox-info could
> end up containing unqualified group names unless g-g-p-n fail somehow.

I'll do this on Monday, sorry for the long intervals but debugging
things at work from home and vice versa is a pain.

Ted