GNU bug report logs - #41842
28.0.50; gnus-new-mail-mark is applied to too many groups

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41842 in the body.
You can then email your comments to 41842 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; gnus-new-mail-mark is applied to too many groups
Date: Sun, 14 Jun 2020 00:14:17 +0100

Severity: minor

I use mbsync to synchronise three remote IMAP inboxes with three local
Maildirs.  I use Dovecot to serve these Maildirs locally over IMAP, each
over a separate connection.  For each local IMAP instance, I add to
gnus-secondary-select-methods a new nnimap entry with a name based on
the corresponding Maildir's basename:

  $ tree -L 1 ~/Mail
  /home/blc/Mail
  ├── outlook
  ├── personal
  └── tcd

gnus-secondary-select-methods:

  ((nnimap "tcd"      ...)
   (nnimap "personal" ...)
   (nnimap "outlook"  ...)
   ...)

I use gnus-topic-mode to organise the subscribed groups of each nnimap
into different topics.  So when mbsync has fetched new mail, and I
either start Gnus, or type g (gnus-group-get-new-news) in an existing
*Group* buffer, I see something like this:

  [ Gnus -- 25888 ]
    [ tcd -- 22671 ]
     %      13?   0! : tcd:INBOX                 13:34
    [ personal -- 79 ]
     %      14?   0! : personal:INBOX            23:27
    [ outlook -- 3 ]
     %       3?   0! : outlook:INBOX            Thu 11

Notice that gnus-new-mail-mark (the % in the fourth column) is on all
three INBOX groups, even though only personal:INBOX contains new mail.

This happens because of the way gnus-group-new-mail in gnus-group.el
checks whether a given group, such as "nnimap+tcd:INBOX", contains new
mail.  It first passes the group name to gnus-group-real-name, which
returns "INBOX", and then passes this result to nnmail-new-mail-p, which
checks for its presence in nnmail-split-history, whose value is
something like:

  ((("INBOX" . 0))
   (("[Gmail].Sent Mail" . 0))
   ...)

Would it be possible for the variable nnmail-split-history, or the
function gnus-group-new-mail, or both, to be changed so they
store/manipulate only the full group name "nnimap+tcd:INBOX"?

Thanks,

-- 
Basil

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2020-06-13 built on thunk
Repository revision: 4823fa1077e4330bd2574eb54731bb32e6370034
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid

Message #8 received at 41842 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 41842 <at> debbugs.gnu.org
Subject: Re: bug#41842: 28.0.50; gnus-new-mail-mark is applied to too many
 groups
Date: Sun, 19 Jul 2020 03:15:36 +0200

"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:

> This happens because of the way gnus-group-new-mail in gnus-group.el
> checks whether a given group, such as "nnimap+tcd:INBOX", contains new
> mail.  It first passes the group name to gnus-group-real-name, which
> returns "INBOX", and then passes this result to nnmail-new-mail-p, which
> checks for its presence in nnmail-split-history, whose value is
> something like:
>
>   ((("INBOX" . 0))
>    (("[Gmail].Sent Mail" . 0))
>    ...)

Hm, that's a kinda badly misdesigned interface...

> Would it be possible for the variable nnmail-split-history, or the
> function gnus-group-new-mail, or both, to be changed so they
> store/manipulate only the full group name "nnimap+tcd:INBOX"?

I think that would be easy to implement for nnimap (it peeks into the
Gnus structures, so it knows the full Gnus name of the group)...

But looking at the code used in nnmail.el (i.e.,
nnmail-check-duplication), it doesn't (at that point) know what the Gnus
group names are; it just gets data from the backends.  (This is when
nnml splits from, say, pop3 fetching.)

So I don't know how to fix this generally.

Any ideas?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 41842 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 41842 <at> debbugs.gnu.org
Subject: Re: bug#41842: 28.0.50; gnus-new-mail-mark is applied to too many
 groups
Date: Wed, 22 Jul 2020 13:57:03 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> "Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
>
>> This happens because of the way gnus-group-new-mail in gnus-group.el
>> checks whether a given group, such as "nnimap+tcd:INBOX", contains new
>> mail.  It first passes the group name to gnus-group-real-name, which
>> returns "INBOX", and then passes this result to nnmail-new-mail-p, which
>> checks for its presence in nnmail-split-history, whose value is
>> something like:
>>
>>   ((("INBOX" . 0))
>>    (("[Gmail].Sent Mail" . 0))
>>    ...)
>
> Hm, that's a kinda badly misdesigned interface...
>
>> Would it be possible for the variable nnmail-split-history, or the
>> function gnus-group-new-mail, or both, to be changed so they
>> store/manipulate only the full group name "nnimap+tcd:INBOX"?
>
> I think that would be easy to implement for nnimap (it peeks into the
> Gnus structures, so it knows the full Gnus name of the group)...
>
> But looking at the code used in nnmail.el (i.e.,
> nnmail-check-duplication), it doesn't (at that point) know what the Gnus
> group names are; it just gets data from the backends.  (This is when
> nnml splits from, say, pop3 fetching.)
>
> So I don't know how to fix this generally.
>
> Any ideas?

Let's change all group names to be fully prefixed everywhere inside
Gnus. If we must preserve the "primary-select-method-is-unprefixed"
convention, just do it at two places at the edges of the system: when
reading/writing .newsrc.eld, and when displaying the group name in the
*Group* buffer.

The first case is important for backward compatibility, but the second
should be dropped as well: provide one format escape for
prefixed-group-name and another for unprefixed-group-name, and let the
user sort it out.

Look at how much code we could remove!

Message #14 received at 41842 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 41842 <at> debbugs.gnu.org
Subject: Re: bug#41842: 28.0.50; gnus-new-mail-mark is applied to too many
 groups
Date: Thu, 23 Jul 2020 15:51:48 +0200

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Let's change all group names to be fully prefixed everywhere inside
> Gnus. If we must preserve the "primary-select-method-is-unprefixed"
> convention, just do it at two places at the edges of the system: when
> reading/writing .newsrc.eld, and when displaying the group name in the
> *Group* buffer.

This isn't about unprefixed group names in Gnus -- it's about group
names in the backends.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 41842 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 41842 <at> debbugs.gnu.org
Subject: Re: bug#41842: 28.0.50; gnus-new-mail-mark is applied to too many
 groups
Date: Thu, 23 Jul 2020 10:00:20 -0700

On 07/23/20 15:51 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Let's change all group names to be fully prefixed everywhere inside
>> Gnus. If we must preserve the "primary-select-method-is-unprefixed"
>> convention, just do it at two places at the edges of the system: when
>> reading/writing .newsrc.eld, and when displaying the group name in the
>> *Group* buffer.
>
> This isn't about unprefixed group names in Gnus -- it's about group
> names in the backends.

Whoops -- ignore me...

Message #20 received at 41842 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 41842 <at> debbugs.gnu.org
Subject: Re: bug#41842: 28.0.50; gnus-new-mail-mark is applied to too many
 groups
Date: Tue, 28 Jul 2020 00:35:56 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> But looking at the code used in nnmail.el (i.e.,
> nnmail-check-duplication), it doesn't (at that point) know what the Gnus
> group names are; it just gets data from the backends.  (This is when
> nnml splits from, say, pop3 fetching.)
>
> So I don't know how to fix this generally.

Aha!

I traced the call sequence up and up to try to find out just how to get
at what the select method was, and it's not present in the nine layers
of calls down to where nnmail-split-history is set...

But!  gnus-command-method is bound!  The unique Gnus group name can be
trivially determined based on that.  I think.

I'll try hacking that up and see what happens...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #23 received at 41842 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 41842 <at> debbugs.gnu.org
Subject: Re: bug#41842: 28.0.50; gnus-new-mail-mark is applied to too many
 groups
Date: Tue, 28 Jul 2020 00:47:48 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> But!  gnus-command-method is bound!  The unique Gnus group name can be
> trivially determined based on that.  I think.
>
> I'll try hacking that up and see what happens...

I...  think it worked?  It's only been lightly tested, though.  Could
check whether this works as it's supposed to in Emacs 28?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #28 received at 41842-done <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 41842-done <at> debbugs.gnu.org
Subject: Re: bug#41842: 28.0.50; gnus-new-mail-mark is applied to too many
 groups
Date: Tue, 28 Jul 2020 13:32:22 +0300

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> But!  gnus-command-method is bound!  The unique Gnus group name can be
>> trivially determined based on that.  I think.
>>
>> I'll try hacking that up and see what happens...
>
> I...  think it worked?  It's only been lightly tested, though.  Could
> check whether this works as it's supposed to in Emacs 28?

Seems to work fine here, thanks!  I'm therefore closing this bug.

-- 
Basil

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.