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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Subject: bug#41842: closed (Re: bug#41842: 28.0.50; gnus-new-mail-mark is
 applied to too many groups)
Date: Tue, 28 Jul 2020 10:33:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#41842: 28.0.50; gnus-new-mail-mark is applied to too many groups

which was filed against the emacs,gnus package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 41842 <at> debbugs.gnu.org.

-- 
41842: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=41842
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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

[Message part 3 (message/rfc822, inline)]

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

Previous Next

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