Subject: Re: bug#70579: 30.0.50; gnus: Wrong unread count in the Group buffer

From: Eric Abrahamsen <[email-masked]>
Date: Thu, 09 May 2024 21:14:19 -0700

Eric Abrahamsen <[email-masked]> writes:

> Eli Zaretskii <[email-masked]> writes:
>
>> Ping!  Eric, can we make some progress here?
>>
>>> Cc: [email-masked]
>>> From: Eric Abrahamsen <[email-masked]>
>>> Date: Thu, 25 Apr 2024 21:34:45 -0700
>>> 
>>> James Thomas via "Bug reports for GNU Emacs, the Swiss army knife of
>>> text editors" <[email-masked]> writes:
>>> 
>>> > - (Preferably starting with an empty drafts folder) Compose a message
>>> >   and save it.
>>> > - Open the drafts group, press e on the message and then kill the new
>>> >   buffer; then (incidentally, if you now do '/ N' then this bug does not
>>> >   arise) delete the message (B DEL)
>>> > - Press q
>>> > - The message count is wrong (but can be corrected with M-g)
>>> >
>>> > cf. In gnus.general (gnus-summary-goto-article "[email-masked]")
>
> I've made some progress here -- the root of the problem seems to be
> that, when we hit "e" in the draft summary buffer to resume editing a
> draft, Gnus "jumps ahead" in message numbers. Basically what "editing"
> actually means is that the old draft is deleted, and a new draft is
> started, but the new draft has a article number that's the previous
> draft's number + 2, and the "draft" group's active number is also
> inflated (for instance (12 . 14) when it should be (12 . 13)). I was
> also able to get it to jump three numbers in some cases.
>
>>>From this point, *any* normal usage will end up correcting the error:
> using "C-c C-k" to kill the editing buffer (instead of "C-x k") or as
> you noted any of the commands that lead to refreshing the unread count.
> But if you don't use any of those commands, you'll see the inflated
> active/unread count when you get back to the *Group* buffer (the "B DEL"
> isn't necessary for the recipe, and in fact at that stage the message
> under point has already been deleted).
>
> That's as far as I've gotten, and I'll keep working on why the article
> number starts off inflated. But in the meantime, the solution is "don't
> do that".

Sorry, that sounded a bit unfriendly, when I was the one who asked you
to submit the bug report! An hour or two of chasing Gnus function calls
will do that to you...