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