Re: bug#72949: Gnus sometimes reports new messages but not showing them on IMAP server

James Thomas <[email protected]> Thu, 12 Sep 2024 12:55:49 +0530
Newsgroups gmane.emacs.gnus.general
Message-ID <[email protected]>
(Forgot to cc this here:)

James Thomas wrote:

> Dan Christensen wrote:
>
>> On Sep 11, 2024, James Thomas via "Bug reports for GNU Emacs, the
>> Swiss army knife of text editors" <[email protected]> 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!
>
> --

--