GNU bug report logs - #72949
[PATCH] Wrong unread count in the Group buffer in nnimap

Previous Next

Full log

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

From: Dan Christensen <jdc <at> uwo.ca>
To: bug-gnu-emacs <at> gnu.org
Cc: ding <at> gnus.org
Subject: Re: bug#72949: Gnus sometimes reports new messages but not showing
 them on IMAP server
Date: Wed, 11 Sep 2024 08:39:31 -0400

On Sep 11, 2024, James Thomas via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> wrote:

> James Thomas wrote:
>
>> I haven't tested this patch (don't really know how to), but this could
>> very well be the cause of this long-standing bug:
>
> Could you check if this patch (the 1st one, which swaps the 0 and 1),
> makes any difference?

I've noticed a long-standing bug, and tried this patch.  Here's the bug:
If I use `B m' or `B c' to move or copy a message from an nnimap group
to a non-existent nnimap group, Gnus asks if I want to create the group.
I say yes, and then it gets created with some faulty parameters that
make the *Group* buffer show odd numbers:

  ("nnimap+rocky:testmove1" 3
   ((1 . 1))
   ((unexist 0) (seen 1)) "nnimap:rocky"
   ((modseq . "3") (uidvalidity . "1549221829") (active 0 . 1) (permanent-flags %Answered %Flagged %Deleted %Seen %Draft %*)))))

Note that article 0 is mentioned twice there.  If I close Gnus, get
rid of the "(unexist 0)", and change the active range to 1 . 1, then
things are good again.

I can consistently reproduce this.

I wondered if the patch in this thread would help, but after applying
it, I'm unable to create the new group in this way.  After hitting `y'
to agree to creating a new group, I get:

Debugger entered--Lisp error: (error "Couldn’t create group nnimap+rocky:testmove4")
  signal(error ("Couldn’t create group nnimap+rocky:testmove4"))
  error("Couldn't create group %s" "nnimap+rocky:testmove4")
  gnus-read-move-group-name("Copy" "nnimap+rocky:testmove1" (50086) "nn:")
  gnus-summary-move-article(nil nil nil copy)
  gnus-summary-copy-article(nil)
  funcall-interactively(gnus-summary-copy-article nil)
  call-interactively(gnus-summary-copy-article nil nil)
  command-execute(gnus-summary-copy-article)

So this patch makes Gnus worse for me, rather than better.  I hope this
reproducible strategy helps pin down a solution.

Dan

Previous Next

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