From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/86032 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH 0/2] two minor fixes for new/empty nnimap group handling Date: Mon, 06 Jul 2015 23:11:43 +0800 Message-ID: <87wpydfhhs.fsf@ericabrahamsen.net> References: <1435750676-710-1-git-send-email-bjorn@mork.no> <878uauhulh.fsf@ericabrahamsen.net> <76F67510-C040-48FB-8CBD-2391F8C1FFB1@mork.no> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1436195581 11003 80.91.229.3 (6 Jul 2015 15:13:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jul 2015 15:13:01 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M34267@lists.math.uh.edu Mon Jul 06 17:12:48 2015 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from lists1.math.uh.edu ([129.7.128.208]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZC84c-0003ci-Go for ding-account@gmane.org; Mon, 06 Jul 2015 17:12:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.84) (envelope-from ) id 1ZC83w-0004t4-Qo; Mon, 06 Jul 2015 10:12:04 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1ZC83t-0004sd-NO for ding@lists.math.uh.edu; Mon, 06 Jul 2015 10:12:01 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1ZC83s-0006P5-F5 for ding@lists.math.uh.edu; Mon, 06 Jul 2015 10:12:01 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZC83p-0006Le-Ez for ding@gnus.org; Mon, 06 Jul 2015 17:11:57 +0200 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZC83n-00034E-R0 for ding@gnus.org; Mon, 06 Jul 2015 17:11:55 +0200 Original-Received: from 111.199.149.245 ([111.199.149.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jul 2015 17:11:55 +0200 Original-Received: from eric by 111.199.149.245 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jul 2015 17:11:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 65 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 111.199.149.245 User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:XEjcRZ5xjYTh1yEoWO/5RXNcbzs= X-Spam-Score: -0.4 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:86032 Archived-At: Bjørn Mork writes: > On July 6, 2015 4:45:46 AM CEST, Eric Abrahamsen wrote: >>Bjørn Mork writes: >> >>> The recent nnimap speedups introduced a couple of regressions wrt >>> new and empty nnimap groups. This prevents Gnus from creating new >>> IMAP groups. >>> >>> These two patches fix the problems for me, but are created in the >>> way I usually do lisp: by mindless trial and error until emacs >>> stops complaining. I.e., there might be much better ways to fix >>> this... >>> >>> Anyway: Works For Me (tm) >>> >>> >>> Bjørn Mork (2): >>> nnimap.el (nnimap-request-group): don't make nil into a list >>> nnimap.el (nnimap-request-group): group could be empty >>> >>> lisp/nnimap.el | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >> >>Hi Bjørn, >> >>I'm guessing you only see this when you move a message from one group >>into a non-existent group, and you're prompted to create the new group, >>and it gives you an error. Is that right? >> >>The group actually is created, it just gives an error when it's >>re-selected. That's because the move/copy process doesn't automatically >>subscribe to the group and register it with Gnus: if you go into the >>*Server* buffer and open the group list for the server in question, >>you'll see the new group there, unsubscribed. > > Yes, that's the typical situation where I see this. I didn't realise that the group isn't immediately subscribed to. > > Btw, does this mean that copying to any unsubscribed group will fail, > or am I misunderstanding? If not, then that doesn't seem right. I do > have a couple of use cases where it makes sense to move or copy into > groups which I'm not interested in subscribing to. I wasn't quite clear about the difference between subscribed and "registered". You can copy into unsubscribed groups without any trouble. "Registered" is a term I made up just to say that Gnus knows about the group and is keeping track of attributes for it -- this ought to be the case no matter what. My proposed solution would both register the group, and subscribe it. An alternative would be to register the group and *not* subscribe it, but given that it's got to be one or the other, I'd lean towards subscribing. What do you think? >>My feeling is that groups which are created as part of the article >>move/copy process should be automatically subscribed to, and registered >>with Gnus (ie entered into gnus-newsrc-hashtb). That would solve this >>problem, and also seems like the Right Thing to Do. >> >>Does anyone have any opinions on this? I'll work up a patch, if not. > > Sounds perfect to me. Thanks > > > Bjørn