Re: nnimap versus tls

[Gaute B Strokkenes <gs234@cam.ac.uk>]

On 7 jul 2003, kai.grossjohann@gmx.net wrote:
> Gaute B Strokkenes <gs234@cam.ac.uk> writes:
>
>> I believe that what is going on is that in one iteration of the
>> loop, we receive the server's last bit of output after
>> accept-process-output has returned, but before we test the loop
>> condition.  That way, (process-status imap-process) will be 'exit;
>> but there will still be output waiting for us that we haven't taken
>> care of yet.  Everything will appear to work swimmingly until Emacs
>> is about to idle, and it checks for process output again.
>
> Okay, then another accept-process-output after the loop ought to
> take care of it.  Right?
>
> Gnah.  I feel so silly with this stupid kind of advice :-/
> I wished I grokked this.

As do I.  However, your advice seems to work.  With the following
imap-wait-for-tag: 

(defun imap-wait-for-tag (tag &optional buffer)
;  (message "imap: waiting for tag `%s'" tag)
  (with-current-buffer (or buffer (current-buffer))
    (gs234-debug (format "imap: START wait for tag `%s'" tag))
    (gs234-debug (format "imap: imap-reached-tag is already: `%s'"
			 imap-reached-tag))
    (let (imap-have-messaged)
      (while (and (null imap-continuation)
		  (memq (process-status imap-process) '(open run))
		  (< imap-reached-tag tag))
	(gs234-debug "imap: going through body of loop")
	(let ((len (/ (point-max) 1024))
	      message-log-max)
	  (unless (< len 10)
	    (setq imap-have-messaged t)
	    (message "imap read: %dk" len))
	  (accept-process-output imap-process
				 (truncate imap-read-timeout)
				 (truncate (* (- imap-read-timeout
						 (truncate imap-read-timeout))
					      1000)))))
      (when (and (null imap-continuation)
		 (< imap-reached-tag tag))
	(gs234-debug "imap: accepting a bit extra...")
	(accept-process-output imap-process
			       (truncate imap-read-timeout)
			       (truncate (* (- imap-read-timeout
					       (truncate imap-read-timeout))
					    1000)))
	(gs234-debug "imap: ...done accepting a bit extra"))
      (when imap-have-messaged
	(message ""))
      (gs234-debug (format "imap: END wait for tag `%s'" tag))
      (gs234-debug (format "imap: imap-reached-tag is now: `%s'" imap-reached-tag))
      (gs234-debug (format "imap: imap-continuation is now: `%s'" imap-continuation))
      (gs234-debug (format "imap: (process-status imap-process) is now: `%s'"
			   (process-status imap-process)))
      (and (memq (process-status imap-process) '(open run))
	   (or (assq tag imap-failed-tags)
	       (progn
		 (if imap-continuation
		     'INCOMPLETE
		   'OK)))))))

I get:

  6 LOGOUT
  imap: START wait for tag `6'
  imap: imap-reached-tag is already: `5'
  imap: going through body of loop
  imap: going through body of loop
  imap: going through body of loop
  imap: going through body of loop
  imap: going through body of loop
  imap: going through body of loop
  imap: going through body of loop
  imap: accepting a bit extra...
  IAF: trying to grab buffer ` *imap source*', proc `imap<1>'

  * BYE kern.srcf.societies.cam.ac.uk IMAP4rev1 server terminating connection
  6 OK LOGOUT completed
  *** Received corrupted data(-9) - server has terminated the connection abnormally
  IAF: imap-state is `auth'
  IAF: punting on imap-parse-response...
  IAF: imap-state is `auth'
  IAF: punting on imap-parse-response...
  imap: ...done accepting a bit extra
  imap: END wait for tag `6'
  imap: imap-reached-tag is now: `6'
  imap: imap-continuation is now: `nil'
  imap: (process-status imap-process) is now: `exit'
  imap: ...closing now done

So we seem to have guessed correctly at last.  ^_^

I'll prepare a (nicer-looking) patch...

-- 
Big Gaute                               http://www.srcf.ucam.org/~gs234/
Is something VIOLENT going to happen to a GARBAGE CAN?