From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/67280 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus and imap Date: Sat, 23 Aug 2008 16:52:52 +0200 Message-ID: <87myj3wzp7.fsf@randomsample.de> References: <877iabwtjx.fsf@randomsample.de> <87abf51c4m.fsf@marauder.physik.uni-ulm.de> <874p5dm35l.fsf@randomsample.de> <87iqttq7ja.fsf@randomsample.de> <87d4k0t7ga.fsf@randomsample.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1219503614 6138 80.91.229.12 (23 Aug 2008 15:00:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Aug 2008 15:00:14 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M15731@lists.math.uh.edu Sat Aug 23 17:01:07 2008 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1KWuby-0002rj-Fh for ding-account@gmane.org; Sat, 23 Aug 2008 17:01:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1KWua3-0007R3-RC; Sat, 23 Aug 2008 09:59:07 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1KWuUA-0007Or-Ed for ding@lists.math.uh.edu; Sat, 23 Aug 2008 09:53:02 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1KWuU7-00027L-4z for ding@lists.math.uh.edu; Sat, 23 Aug 2008 09:53:02 -0500 Original-Received: from m61s02.vlinux.de ([83.151.21.164]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1KWuU7-0004AB-00 for ; Sat, 23 Aug 2008 16:52:59 +0200 Original-Received: from dslb-082-083-041-056.pools.arcor-ip.net ([82.83.41.56] helo=honk) by m61s02.vlinux.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KWuUR-0001hS-19 for ding@gnus.org; Sat, 23 Aug 2008 16:53:19 +0200 Mail-Copies-To: never Mail-Followup-To: ding@gnus.org In-Reply-To: (Vitaly Mayatskikh's message of "Sat, 23 Aug 2008 13:32:02 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/22.2.90 (gnu/linux) X-Spam-Score: 0.0 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:67280 Archived-At: Vitaly Mayatskikh writes: >> The problem lies in gnus-read-active-file-2, which is called by >> gnus-get-unread-articles. This uses nnimap-retrieve-groups to get a >> partial active file of the checked groups, which is of the "regular" >> (max . min) style and overwrites the previous "new" active sequence in >> the hash table. > > I can't get this scenario (probably, due to different settings). Will dig > around more. Try playing with gnus-read-active-file and call gnus-group-get-new-news with a level argument. nnimap is my primary select method, maybe this also comes into play. I tested this with (save-excursion (set-buffer gnus-group-buffer) (gnus-group-jump-to-group "sent") (gnus-group-get-new-news-this-group) (princ (gnus-active "sent") t);; will return full range (gnus-group-get-new-news 3) (princ (gnus-active "sent") t) ;; returns one range, e.g. (1 . 2500) ) >> Anyway, I have the feeling this gets messy. I'm not sure if this is the >> right way to do this. The main problem I see is that this will break any >> code which depends on gnus-active returning the cons (max . min). For >> example, this currently breaks nnmairix, which isn't that much of a >> problem since I can change this. But I wonder how much external code >> exists which uses gnus-active. > > As I understand, this change affects only "middle level" back ends like > yours nnmairix, which lays in between of Gnus and real transport back > ends. Of course, it is hard to say what exactly can be broken. That's right (both statements). >> What about not extending the group info, but putting the unread sequence >> in the existing marks section. Either the back end does this, then it >> can be included, or we do it the old way. Just a suggestion, I don't >> know if this works. As I said, I'm not that familiar with the back end >> internals. > > I'm only afraid of spaghetti code. For me it's better to have one clean > and consistent solution. Absolutely. The problem is that active information is used throughout Gnus, and the code is in parts already pretty convoluted, especially the ones dealing with updating groups and checking for unread messages. I guess that putting unread information in gnus-info would affect fewer parts of the code. Another suggestion: maybe all this work should be strictly kept in the back end itself? We could implement a new back end function, like 'nnimap-unread-articles GROUP SERVER', which just returns the number of unread articles. We can check for the existence of specific back end functions with gnus-check-backend-function, so no need for additional flags. -David