From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Deus Max <deusmax@gmx.com>
Cc: 39618@debbugs.gnu.org
Subject: bug#39618: 28.0.50; gnus nnimap reports more group articles than actually exist
Date: Tue, 18 Feb 2020 13:36:55 -0800 [thread overview]
Message-ID: <87eeur4lxk.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <877e0jwtx8.fsf@aia00054aia.gr> (Deus Max's message of "Tue, 18 Feb 2020 21:56:51 +0200")
On 02/18/20 21:56 PM, Deus Max wrote:
> On Sun, Feb 16 2020, Eric Abrahamsen wrote:
>
>> Deus Max <deusmax@gmx.com> writes:
>>
>>> Recently my gnus started displaying (in the *Group* buffer) some groups
>>> (which had previously no unread articles) with an unread "ghost" article
>>> but which groups could not be normally entered.
>>>
>>> Here is a description of what I observed:
>>>
>>> 1. When pressing <Return>, the cursor simply moves on to the next group
>>> line. The number of unread articles remains unchanged and non-zero.
>>> 2. When pressing <c> for `gnus-group-catchup-current', the unread
>>> article number becomes zero and upon <Return>, all read articles are
>>> displayed in the group. Upon exit from the group, upon "g"
>>> gnus-refresh the "ghost" unread article reappears.
>>>
>>> Luckily, this being nnimap the situation can be recovered by removing
>>> the .newsrc files and restarting gnus from scratch. This is not optimal,
>>> as all other relevant configurations will be lost, such as group levels,
>>> etc.
>>>
>>> This issue has happened before, it is not the first time.
>>
>> This definitely happens to many of us from time to time. Unfortunately I
>> can't really reproduce the problem, as by the time it appears it's too
>> late to figure out where it came from, though I assume it has to do with
>> Gnus calculating unread messages from a high-low range, and not being
>> aware of "filled in" read messages within that range.
>>
> You think this is a nnimap or a general Gnus issue ?
I don't know. I suspect that it's a general Gnus issue, but it is more
evident with nnimap, since that's pretty much the only (?) server where
local marks must be kept in sync with a remote server. In principle,
there's no reason why Gnus would need to keep local marks for imap
groups.
> Understanding how the newsrc file is written, should be next for me.
It's just, with their lists of marks. The lists are in "gnus range"
format (see gnus-range.el), which is just a compressed list of integers:
'(1 2 3 4 6 12 21 22 23) => '((1. 4) 6 12 (21. 23))
They are treated as sets, with lots of the usual set manipulation
functions in gnus-range.el. Part of the problem is the direct
manipulation of ranges that happens elsewhere in the codebase, typically
impenetrable thickets of "(setcdr (nthcdr 3 range) (cadar range)" etc
etc, often with little or no comments.
On my (long) list of things to do with Gnus is to write several more
macros for range manipulation, so that all the messy stuff happens
inside gnus-range.el, and the rest of the codebase is fairly readable.
My hope is that, in the course of that process, bugs will show
themselves up.
> Is there any type of tracing, or profiling to turn on, until this
> happens again ? Maybe set the gnus and back-end log levels to 10 ?
Nothing that would show you anything about range manipulation, I don't
think.
> The primary thing a mail, em..sorry.. news-reader, should be is stable.
> Not to have any corruption issues.
No argument here...
>> In the meantime, is "M-g" on the problematic group(s) enough to
>> permanently fix the problem? Not a great solution, though better than
>> doctoring your .newsrc.eld file...
>
> No difference. On testing your suggestion, the "M-g" was ignored as
> was/is the regular "g".
Sorry, I don't know where else to look. My only solution is the hard
one: clean up range manipulation until we can see what's going on.
next prev parent reply other threads:[~2020-02-18 21:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-15 19:25 bug#39618: 28.0.50; gnus nnimap reports more group articles than actually exist Deus Max
2020-02-16 22:53 ` Eric Abrahamsen
2020-02-18 19:56 ` Deus Max
2020-02-18 21:36 ` Eric Abrahamsen [this message]
2020-02-19 20:06 ` Deus Max
2020-02-19 22:08 ` Eric Abrahamsen
2020-02-20 12:57 ` Lars Ingebrigtsen
2020-02-20 18:56 ` Eric Abrahamsen
2020-02-20 12:56 ` Lars Ingebrigtsen
2020-02-20 20:42 ` Deus Max
2020-02-20 20:48 ` Lars Ingebrigtsen
2020-02-20 21:35 ` Deus Max
2020-07-19 14:07 ` Lars Ingebrigtsen
2020-07-27 10:29 ` Deus Max
2020-07-27 15:44 ` Eric Abrahamsen
2020-07-27 16:41 ` Deus Max
2020-07-27 21:57 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eeur4lxk.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=39618@debbugs.gnu.org \
--cc=deusmax@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.