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

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

[Basil L. Contovounesios]

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

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

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@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

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

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@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!

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

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@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

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

[Eric Abrahamsen]

On 07/23/20 15:51 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@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...

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

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

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@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