emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43129: closed (25.2; Typo in lisp/gnus/nnimap.el)


From: GNU bug Tracking System
Subject: bug#43129: closed (25.2; Typo in lisp/gnus/nnimap.el)
Date: Wed, 02 Sep 2020 16:10:02 +0000

Your message dated Wed, 02 Sep 2020 09:09:40 -0700
with message-id <87h7sg9n3v.fsf@ericabrahamsen.net>
and subject line Re: bug#43129: 25.2; Typo in lisp/gnus/nnimap.el
has caused the debbugs.gnu.org bug report #43129,
regarding 25.2; Typo in lisp/gnus/nnimap.el
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
43129: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43129
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 25.2; Typo in lisp/gnus/nnimap.el Date: Mon, 31 Aug 2020 03:47:18 -0400
In commit fc9206b73a254a400245578b94542cfe82c68e9c, when IMAP MOVE
extension support was added,

the line

(or (nnimap-find-uid-response "COPYUID" (cadr result))

was replaced with

(or (nnimap-find-uid-response "COPYUID" (caddr result))

which results in a significant slowing of internal-move-group article
movement as the call to nnimap-find-uid-response always fails as caddr
always returns nil, AFAICT based on testing with example server
responses given in IMAP RFCs and those from two different IMAP servers,
leading Gnus to make a slow call to nnimap-find-article-message-id
insead of using the article number provided by the COPYUID response.

Simple patch, which undoes the switch from cadr to caddr:

diff --git a/lisp/gnus/nnimap.el b/lisp/gnus/nnimap.el
index be8ad9a672..baf90d38ad 100644
--- a/lisp/gnus/nnimap.el
+++ b/lisp/gnus/nnimap.el
@@ -986,7 +986,7 @@ nnimap-request-move-article
                 (when (and (car result) (not can-move))
                   (nnimap-delete-article article))
                 (cons internal-move-group
-                      (or (nnimap-find-uid-response "COPYUID" (caddr result))
+                      (or (nnimap-find-uid-response "COPYUID" (cadr result))
                           (nnimap-find-article-by-message-id
                            internal-move-group server message-id
                            nnimap-request-articles-find-limit)))))
Cautious patch, which would handle cases where caddr is appropriate, if
there are any:

diff --git a/lisp/gnus/nnimap.el b/lisp/gnus/nnimap.el
index be8ad9a672..cea8988f81 100644
--- a/lisp/gnus/nnimap.el
+++ b/lisp/gnus/nnimap.el
@@ -986,7 +986,8 @@ nnimap-request-move-article
                 (when (and (car result) (not can-move))
                   (nnimap-delete-article article))
                 (cons internal-move-group
-                      (or (nnimap-find-uid-response "COPYUID" (caddr result))
+                      (or (nnimap-find-uid-response "COPYUID" (cadr result))
+                          (nnimap-find-uid-response "COPYUID" (caddr result))
                           (nnimap-find-article-by-message-id
                            internal-move-group server message-id
                            nnimap-request-articles-find-limit)))))
sean

--- End Message ---
--- Begin Message --- Subject: Re: bug#43129: 25.2; Typo in lisp/gnus/nnimap.el Date: Wed, 02 Sep 2020 09:09:40 -0700 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
On 09/02/20 01:38 AM, Sean Connor wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> And my dovecot test was done in a clean environment where, by default,
>> Gnus doesn't let dovecot use MOVE, so in effect I was only testing
>> COPY as well. Looks like cautious is the way to go!
>
> Yes.
>
> [...]
>
>> Thanks, this is helpful. I feel like the "outer edges" of execution is
>> the wrong place to be checking this stuff -- if the response parsing
>> process handled the differences, this would never have been an issue in
>> the first place. And ugh, this can-move thing is all over the place, and
>> begging to be refactored...
>
> I don't know.
>
>> But! We will not be drawn down that rabbit hole. It seems to me that
>> changing the code to read:
>>
>
> [code]
>
> Nice.  That's much clearer.
>
> [...]
>
>>> I tested with courier, dovecot, RFC sample sessions and gmail IMAP
>>> transcripts, FWIW.
>>
>> That's good to know! That gives us some confidence.
>
> Yep.
>
> Thank you.

In it goes! Thanks for the report.

Eric


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]