From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.bugs Subject: bug#39618: 28.0.50; gnus nnimap reports more group articles than actually exist Date: Tue, 18 Feb 2020 13:36:55 -0800 Message-ID: <87eeur4lxk.fsf@ericabrahamsen.net> References: <877e0nlkk6.fsf@aia00054aia.gr> <875zg6kuue.fsf@ericabrahamsen.net> <877e0jwtx8.fsf@aia00054aia.gr> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="119758"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 39618@debbugs.gnu.org To: Deus Max Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 18 22:38:18 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j4AZO-000V2v-Mh for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 18 Feb 2020 22:38:18 +0100 Original-Received: from localhost ([::1]:42184 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4AZN-0001Lt-IR for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 18 Feb 2020 16:38:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49402) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4AZ9-0001Le-97 for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 16:38:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4AZ8-0000jG-2m for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 16:38:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35410) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4AZ7-0000ik-V9 for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 16:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j4AZ7-00059V-Sl for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 16:38:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eric Abrahamsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Feb 2020 21:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39618 X-GNU-PR-Package: emacs Original-Received: via spool by 39618-submit@debbugs.gnu.org id=B39618.158206182519723 (code B ref 39618); Tue, 18 Feb 2020 21:38:01 +0000 Original-Received: (at 39618) by debbugs.gnu.org; 18 Feb 2020 21:37:05 +0000 Original-Received: from localhost ([127.0.0.1]:41383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4AYC-000583-Qp for submit@debbugs.gnu.org; Tue, 18 Feb 2020 16:37:05 -0500 Original-Received: from ericabrahamsen.net ([52.70.2.18]:55166 helo=mail.ericabrahamsen.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4AYA-00057W-NC for 39618@debbugs.gnu.org; Tue, 18 Feb 2020 16:37:03 -0500 Original-Received: from localhost (c-73-254-86-141.hsd1.wa.comcast.net [73.254.86.141]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id B78A8FA12C; Tue, 18 Feb 2020 21:36:56 +0000 (UTC) In-Reply-To: <877e0jwtx8.fsf@aia00054aia.gr> (Deus Max's message of "Tue, 18 Feb 2020 21:56:51 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:176220 Archived-At: On 02/18/20 21:56 PM, Deus Max wrote: > On Sun, Feb 16 2020, Eric Abrahamsen wrote: > >> Deus Max 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 , the cursor simply moves on to the next group >>> line. The number of unread articles remains unchanged and non-zero. >>> 2. When pressing for `gnus-group-catchup-current', the unread >>> article number becomes zero and upon , 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.