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

Previous Next

Full log

View this message in rfc822 format

From: James Thomas <jimjoe <at> gmx.net>
To: 72949 <at> debbugs.gnu.org
Subject: bug#72949: Gnus sometimes reports new messages but not showing them on IMAP server
Date: Thu, 12 Sep 2024 06:40:58 +0530

Dan Christensen wrote:

> 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.

Sorry! I got confused again... Please try the other patch in that bug
report (the one that swaps the car and cdr). I find that it works with
your use case!

--

Previous Next

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