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