From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.user/17032 Path: news.gmane.org!not-for-mail From: Carlos Pita Newsgroups: gmane.emacs.gnus.user Subject: Re: Misbehaving gnus-gcc-mark-as-read while archiving to current group Date: Tue, 12 Aug 2014 13:28:07 -0300 Organization: Gnus News User Services Message-ID: <84sil1llk8.fsf@gmail.com> References: <86fvhbkktq.fsf@gmail.com> <871tsupnim.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1407860417 29328 80.91.229.3 (12 Aug 2014 16:20:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Aug 2014 16:20:17 +0000 (UTC) To: info-gnus-english@gnu.org Original-X-From: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Tue Aug 12 18:20:12 2014 Return-path: Envelope-to: gegu-info-gnus-english@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XHEnu-0006ZC-E5 for gegu-info-gnus-english@m.gmane.org; Tue, 12 Aug 2014 18:20:06 +0200 Original-Received: from localhost ([::1]:43085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHEnt-0005F0-Qg for gegu-info-gnus-english@m.gmane.org; Tue, 12 Aug 2014 12:20:05 -0400 Original-Path: usenet.stanford.edu!news.glorb.com!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!news.tele.dk!news.tele.dk!small.news.tele.dk!uio.no!quimby.gnus.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.gnus Original-Lines: 50 Original-NNTP-Posting-Host: 190.216.58.35 Original-X-Trace: quimby.gnus.org 1407860002 15104 190.216.58.35 (12 Aug 2014 16:13:22 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: Tue, 12 Aug 2014 16:13:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.92 (gnu/linux) Cancel-Lock: sha1:NxqDYZdwQ/M5WfTU98DAlLMzqeQ= Original-Xref: usenet.stanford.edu gnu.emacs.gnus:88162 X-BeenThere: info-gnus-english@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader \(in English\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Original-Sender: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.gnus.user:17032 Archived-At: Hi, thank you for your detailed answer, Emanuel. Since then I've been exploring the issue from time to time, a bit overwhelmed by the magnitude of gnus code, and I do think there is a bug, indeed. The problem is that gnus-summary-insert-new-articles assumes every new active article to be unread: (setq gnus-newsgroup-unreads (gnus-sorted-nunion gnus-newsgroup-unreads new)) It seems like a sensible assumption, doesn't it? But sadly it's wrong in this case, because the sent mail is meant to be already read. It will be wrong in other cases too, since a "new" message coming from the imap server, which could be simultaneously accessed by more than one client, is not necessarily unread. So currently you have 3 levels of inconsistency: 1) The imap server and M-g "think" the email is read. 2) /N "thinks" the email is unread. 3) The summary buffer (before /N or M-g) "thinks" there is no email. I believe there is a very easy way to reduce these inconsistencies to only: 1) The imap server, M-g, /N "think" the email is read. 2) The summary buffer (before /N or M-g) "thinks" there is no email. Then you can just say that the summary buffer isn't immediately refreshed, which doesn't feel so bad and is easier to understand and live with. Notice that gnus-summary-insert-new-articles is calling gnus-summary-insert-articles, which already calculates the unread list using gnus-list-of-unread-articles. So it seems to me that removing the problematic union operation quoted above would be safe since gnus-summary-insert-articles is already taking care of that. I've reported this as a bug a number of days ago, and I would like to add the above remark as a followup or commentary to the report, but I'm not able to find instructions on how to do that. Cheers -- Carlos