GNU bug report logs - #70579
30.0.50; gnus: Wrong unread count in the Group buffer

Previous Next

Full log

View this message in rfc822 format

From: James Thomas <jimjoe <at> gmx.net>
To: 70579 <at> debbugs.gnu.org
Cc: Eric Abrahamsen <eric <at> ericabrahamsen.net>, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#70579: 30.0.50; gnus: Wrong unread count in the Group buffer
Date: Fri, 10 May 2024 16:31:12 +0530

Eric Abrahamsen wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Ping!  Eric, can we make some progress here?
>>
>>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>>> Date: Thu, 25 Apr 2024 21:34:45 -0700
>>> 
>>> James Thomas via "Bug reports for GNU Emacs, the Swiss army knife of
>>> text editors" <bug-gnu-emacs <at> gnu.org> 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 "87y192lr8f.fsf <at> gmx.net")
>
> 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".

Of course. I was only hoping that this would shed some light on the
other unread-count problems.... IMO this is low-severity.

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

A more-than-reasonable trade-off of expressiveness for the ultimate
cause. 🙂

>>> 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...
>
> Okay, I found two things, one the proximate cause of this bug, another
> "probably wrong" adjacent issue.
>
> The main problem is that `gnus-draft-setup' both calls `message-mode'
> (which calls `message-set-auto-save-file-name'), and then directly calls
> `message-set-auto-save-file-name' itself. Without getting into horrible
> details, that functions shouldn't be called twice, because it generates
> an extra numerical file name, which ends up inflating the active value
> of the drafts group.
>
> I've attached a patch that removes the second call. If you feel
> comfortable applying and testing patches, I hope you'll try it. In my
> experiments it fixes the problem.
>
> The patch also semi-addresses the second issue. When saving a draft,
> message-mode only buries the buffer, it doesn't delete it. If you go
> back and start editing the draft, `gnus-draft-check-draft-articles' is
> supposed to see if a there's already a buffer visiting the draft file,
> and return you to that buffer instead of creating a new one. But it only
> does that if the buffer is modified, which it isn't if you've
> saved/buried the draft.
>
> I don't see why that should mean that you need a whole new buffer for
> editing the message

I can see a possible use case: you might want two versions of a draft
message, one being a 'root' (or 'base') version.

> , and the fact that there are now two "copies" of the
> message buffer causes further problems with the inflating article
> numbers (why I could sometimes see three or even four "jumps").
>
> The patch removes the check for modification

If my guess above is correct, this should be avoided.

> Anyway, please let me know if you can check the patch.

So I checked only the first hunk, and it worked, but seems to have
caused another problem: If I now open the group and view an existing
draft with RET, and then 'q', the message disappears - in both the
count, and if the group is reopened. M-g reverts things back to normal.

There's also a small hiccup with its working: 'B DEL' in the recipe
above does not work (i.e. it's not deleted - is it related to it already
being marked with 'G' at that point?), unless I 'q', re-enter and retry.

Regards,
James

Previous Next

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