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: Wed, 19 Feb 2020 14:08:57 -0800 [thread overview]
Message-ID: <878sky9qme.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <871rqqwdcs.fsf@aia00054aia.gr> (Deus Max's message of "Wed, 19 Feb 2020 22:06:59 +0200")
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
next prev parent reply other threads:[~2020-02-19 22:08 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
2020-02-19 20:06 ` Deus Max
2020-02-19 22:08 ` Eric Abrahamsen [this message]
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=878sky9qme.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.