From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/86083 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH] Use IMAP MOVE extension if available Date: Sun, 02 Aug 2015 13:56:48 +0800 Message-ID: <87oaiqs067.fsf@ericabrahamsen.net> References: <87io9l2bd0.fsf@vostro.rath.org> <87y4ibf93c.fsf@ericabrahamsen.net> <87wpxuerau.fsf@thinkpad.rath.org> <878ua2cj3m.fsf@ericabrahamsen.net> <87r3nta8e8.fsf@thinkpad.rath.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438495114 11974 80.91.229.3 (2 Aug 2015 05:58:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Aug 2015 05:58:34 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M34317@lists.math.uh.edu Sun Aug 02 07:58:22 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 1ZLmHt-0003gX-Po for ding-account@gmane.org; Sun, 02 Aug 2015 07:58:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.85) (envelope-from ) id 1ZLmGk-00078t-Kf; Sun, 02 Aug 2015 00:57:10 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.85) (envelope-from ) id 1ZLmGi-00078R-B9 for ding@lists.math.uh.edu; Sun, 02 Aug 2015 00:57:08 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZLmGg-0005W6-SO for ding@lists.math.uh.edu; Sun, 02 Aug 2015 00:57:08 -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 1ZLmGf-0001Y8-Fn for ding@gnus.org; Sun, 02 Aug 2015 07:57:05 +0200 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZLmGd-0003Ju-LR for ding@gnus.org; Sun, 02 Aug 2015 07:57:05 +0200 Original-Received: from 114.250.116.101 ([114.250.116.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 02 Aug 2015 07:57:03 +0200 Original-Received: from eric by 114.250.116.101 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 02 Aug 2015 07:57:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 73 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 114.250.116.101 User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:oiZwS+oaNwjB6H9e1mipWE0ZZL4= X-Spam-Score: 0.2 (/) X-Spam-Report: SpamAssassin (3.4.1 2015-04-28) analysis follows Bayesian score: 0.0000 Ham tokens: 0.000-1287--66703h-0s--0d--diff, 0.000-1275--66086h-0s--0d--100644, 0.000-427--22124h-0s--0d--patch, 0.000-296--15334h-0s--0d--PATCH, 0.000-31--1601h-0s--1d--formats Spam tokens: 0.994-11353--365h-6821s--0d--H*RU:quimby.gnus.org, 0.994-11353--365h-6821s--0d--Hx-spam-relays-external:quimby.gnus.org, 0.994-10719--365h-6452s--0d--HTo:D*gnus.org, 0.993-11277--441h-6821s--0d--Hx-spam-relays-internal:80.91.231.51, 0.993-11277--441h-6821s--0d--Hx-spam-relays-internal:quimby.gnus.org Autolearn status: no autolearn_force=no -1.0 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [80.91.229.3 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record 1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 2.0 FSL_HELO_BARE_IP_2 No description available. List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:86083 Archived-At: Nikolaus Rath writes: > On Jul 27 2015, Eric Abrahamsen wrote: >> diff --git a/lisp/nnimap.el b/lisp/nnimap.el >> index 161a6b4..f8e6e3e 100644 >> --- a/lisp/nnimap.el >> +++ b/lisp/nnimap.el >> @@ -489,11 +489,18 @@ textual parts.") >> (when (functionp (nth 2 credentials)) >> (funcall (nth 2 credentials))) >> ;; See if CAPABILITY is set as part of login >> - ;; response. >> - (dolist (response (cddr login-result)) >> - (when (string= "CAPABILITY" (upcase (car response))) >> - (setf (nnimap-capabilities nnimap-object) >> - (mapcar #'upcase (cdr response)))))) >> + ;; response. If it wasn't, specifically request >> + ;; it. >> + (when >> + (catch 'caps >> + (dolist (response (cddr login-result)) >> + (when (string= "CAPABILITY" (upcase (car response))) >> + (throw 'caps (setq capabilities (cdr response))))) >> + (let ((req (nnimap-command "CAPABILITY"))) >> + (when (car req) >> + (throw 'caps (setq capabilities (cdaddr req)))))) >> + (setf (nnimap-capabilities nnimap-object) >> + (mapcar #'upcase capabilities)))) >> ;; If the login failed, then forget the credentials >> ;; that are now possibly cached. >> (dolist (host (list (nnoo-current-server 'nnimap) > > > This looks a lot more complex, but as far as I can tell it still > needlessy asks for capabilities if they have been supplied in the > response code of OK response instead of a in separate, untagged > response. So is it really worth the extra complexity, if in many cases > we still issue an explicit CAPABILITY command? > > (For everyone unfamiliar with RFC3501, what I mean is that this: > > * CAPABILITY IMAP4rev1 AND SOME MORE \r\n > 1 OK Logged in\r\n > > will be parsed correcly but this: > > 1 OK [CAPABILITY IMAP4rev1 AND SOME MORE] Logged in\r\n > > will still cause Gnus to issue a separate CAPABILITY command). Okay, I pushed the CAPABILITY patch, and the MOVE patch right after that. Sorry this is all going so slowly! I still think that we'll be able to come up with something that doesn't unconditionally issue an extra CAPABILITY command. My patch was more complex, but at least it avoided redundancy in *some* cases -- now we're always doing the extra command. Are you sure that `nnimap-parse-response' and `nnimap-parse-line' can't handle the bracket case above? I haven't had time to test yet, but looking at the code it seems like it ought to be able to handle it. If there are multiple commonly-used formats for IMAP server responses, it seems like we really ought to be handling them at the base level, when parsing responses. I'll admit I only started learning about IMAP about six months ago, so I'm happy to take other people's word on how all this works. Out of curiosity, is there a particular server that returns the kind of response you note above? I suppose we should be making a list of known-good IMAP servers that Gnus can interact happily with. Yours, Eric