bug#39618: 28.0.50; gnus nnimap reports more group articles than actually exist

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Deus Max <deusmax@gmx.com> writes:

> On Tue, Feb 18 2020, Eric Abrahamsen wrote:
>
>> 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.
>>>>>
> snip
>>>>> 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.
>>
> Hey ! Maybe you have a point here.
> Simplifying nnimap not to keep track of local marks, may not only reduce
> complexity but also take care of this problem.
> If it's not needed, it's a waste. What do you think ?
>
> Of course, some info needs to be kept to avoid the heavy load that
> occurs when one starts with an empty .newsrc.
> For one, we have the group names...

I think this is one of those things that sounds like it would be a great
idea, but would turn into an enormous mess if we tried to implement it.
Not that it's not worth doing, mind you!

>>> 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.
>>
> Really interesting, thanks.
> Sounds like a complete re-write of Gnus (streamlined of course!) is
> hiding behind what you just said :-)

Ha, I hope not! In fact, I think not keeping track of imap group marks
would be far more work. In this case, all we'd be doing is creating more
macros that could be used to gradually hide the implementation of
ranges. That could be done incrementally, as we had time.

>
>>> 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.
>
> Thanks
> I didn't find any other similar bug reports on debbugs. Is that just my
> terrible search abilities ?

Dunno, probably not. I think there have been several conversations about
it on gnus.general, but maybe no bugs reports? Anyway, I think it's
worth leaving this one open.

Yours,
Eric