bug#30022: gnus nnimap-sequence vs yahoo hang

bug#30022: gnus nnimap-sequence vs yahoo hang

[Lars Ingebrigtsen]

Kevin Ryde <user42_kevin@yahoo.com.au> writes:

> With the gnus included in recent debian packaged i386 emacs 25.2, in the
> Group buffer, an M-g to get count of messages of a foreign imap group at
> imap.mail.yahoo.com hangs.  If C-g to stop then a second M-g succeeds.
>
> Sticking in some protocol trace showed
>
>     out >> 1 CAPABILITY
>     out >> 1 LOGIN "username" "password"

Hm, that looks wrong.  nnimap should be increasing the sequence
number...

When I switch nnimap tracing on (by setting `nnimap-record-commands' to
t and looking in the " *imap log*" (note leading space) buffer, then I
get

1 LOGIN
2 CAPABILITY

which is what I'd expect.

Could you include the data from the logging buffer?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#30022: gnus nnimap-sequence vs yahoo hang

[Kevin Ryde]

Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> When I switch nnimap tracing on (by setting `nnimap-record-commands' to
> t and looking in the " *imap log*" (note leading space) buffer, then I
> get
>
> 1 LOGIN
> 2 CAPABILITY

Yes, I see similar

    18:16:44 [imap.mail.yahoo.com] (inhibited)
    18:16:44 [imap.mail.yahoo.com] 2 CAPABILITY^M
    18:16:50 [imap.mail.yahoo.com] 3 SELECT "INBOX"^M

But I think this does not include output of open-protocol-stream
:capability-command "1 CAPABILITY" (in nnimap-open-connection-1).

I saw my trace by putting a front-end on gnutls-cli to print data sent
and received.

Could show :capability-command in *imap log* for completeness, since
it's a command sent.  That plus less inhibiting the login command could
have hinted at the problem.

bug#30022: gnus nnimap-sequence vs yahoo hang

[Lars Ingebrigtsen]

Kevin Ryde <user42_kevin@yahoo.com.au> writes:

> Yes, I see similar
>
>     18:16:44 [imap.mail.yahoo.com] (inhibited)
>     18:16:44 [imap.mail.yahoo.com] 2 CAPABILITY^M
>     18:16:50 [imap.mail.yahoo.com] 3 SELECT "INBOX"^M
>
> But I think this does not include output of open-protocol-stream
> :capability-command "1 CAPABILITY" (in nnimap-open-connection-1).

Oh, I see.  Well spotted.  I think the simplest solution here is to
start off the nnimap sequence at a higher number so that these things
don't get in each others way.

Does the following patch (pushed to Emacs master now) fix the problem
for you?

diff --git a/lisp/gnus/nnimap.el b/lisp/gnus/nnimap.el
index 01d7948afb..65d40eba69 100644
--- a/lisp/gnus/nnimap.el
+++ b/lisp/gnus/nnimap.el
@@ -1865,7 +1865,7 @@ nnimap-find-connection
 	(setq nnimap-connection-alist (delq entry nnimap-connection-alist))
 	nil))))
 
-(defvar nnimap-sequence 0)
+(defvar nnimap-sequence 5)
 
 (defun nnimap-send-command (&rest args)
   (setf (nnimap-last-command-time nnimap-object) (current-time))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#30022: gnus nnimap-sequence vs yahoo hang

[Kevin Ryde]

Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> Does the following patch (pushed to Emacs master now) fix the problem
> for you?
>
> -(defvar nnimap-sequence 0)
> +(defvar nnimap-sequence 5)

Yes.  Per my original report it's enough to set 1 if you like.
It's pre-incremented so the first command sent is sequence 2 which is
after 1 CAPABILITY.