From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/53340 Path: main.gmane.org!not-for-mail From: Gaute B Strokkenes Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap versus tls Date: Mon, 07 Jul 2003 08:26:17 +0100 Organization: The Church of Emacs Sender: ding-owner@lists.math.uh.edu Message-ID: <873chiiyqu.fsf@cam.ac.uk> References: <87ptmfhxj6.fsf@cam.ac.uk> <84of0ab15z.fsf@lucy.is.informatik.uni-duisburg.de> <87k7axwef3.fsf@cam.ac.uk> <843chlyw19.fsf@lucy.is.informatik.uni-duisburg.de> <87adbrq0dy.fsf@cam.ac.uk> <84he5z4pne.fsf@lucy.is.informatik.uni-duisburg.de> <873chjtj8o.fsf@cam.ac.uk> <848yraamxb.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1057562801 19543 80.91.224.249 (7 Jul 2003 07:26:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 7 Jul 2003 07:26:41 +0000 (UTC) Original-X-From: ding-owner+M1884@lists.math.uh.edu Mon Jul 07 09:26:39 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19ZQOU-00054z-00 for ; Mon, 07 Jul 2003 09:26:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19ZQOy-0005cw-00; Mon, 07 Jul 2003 02:27:08 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19ZQOq-0005cq-00 for ding@lists.math.uh.edu; Mon, 07 Jul 2003 02:27:00 -0500 Original-Received: (qmail 79301 invoked by alias); 7 Jul 2003 07:27:00 -0000 Original-Received: (qmail 79296 invoked from network); 7 Jul 2003 07:27:00 -0000 Original-Received: from mta07-svc.ntlworld.com (62.253.162.47) by sclp3.sclp.com with SMTP; 7 Jul 2003 07:27:00 -0000 Original-Received: from belldandy ([81.100.93.186]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030707072656.LMZS18592.mta07-svc.ntlworld.com@belldandy> for ; Mon, 7 Jul 2003 08:26:56 +0100 Original-Received: from gs234 by belldandy with local (Exim 3.36 #1 (Debian)) id 19ZQO9-0000lA-00 for ; Mon, 07 Jul 2003 08:26:17 +0100 Mail-Copies-To: never Original-To: ding@gnus.org Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEWWWBTly7aGMwb+/vz9 +ffIilb///+yaCxNCwHGVC3gAAACU0lEQVR4nF2TQWvjMBBGVUGwj3WxaY/aAWNfi0zuwZPuHp0Q ob079OwYjHrsChb0s3dGctJ0ddTzm9F8lsR7WiNiWWL/flviul9Uh0NR4vY/gJUxJjOEtt/AubBy UsotRfH2DbxWE0hom3w5XJUEKis9hACt2hR4B86VDOtqTNHfgeEGvLiUN7Ddze26Dx6y1CUa+ygo NwFQm0N/BeMzCZAtNIoQrd9EhcH5mWpnztB8ZpJBlH23jaAbuE4EhZ2Bam0TeJ0DRMCKVP6CegWk q4z2TVFUx0946FOPcSe9ELE3rSHAj15rBuddS0C4BGyAutfpVAQkKdZOQiwMMIHxlUDrgeej5Ns7 I/ccSWNBLda1XwYBEG1Qswy1yXJf879nA4cjkNI0H+FzoUyuRodPA5eqZwFONG34i30ccOxeKFUy flNe1szqsgLdvXwKCj6zjTXODHV9M46gZPCLlYKCGTYO8S0aOAvJzRfD0w+1XcGIsxLUw/sYl5sM 9n0yjkoSUDOByrijwRRiAq13NhqLJYB3ACazrgN2bIwanyJQKXhHAJPRPQruEaCJP2Shy4DJ2As+ FQjJZH7AZIy6w0pQiiRYAh8nTEZHYDfRqSDeB5OXq4EEcAC4NocvoBl4+n1cyl54nyLRNA3iIwRP wNGFOK1g1Gz8jNfaCjdtqJLm2LXuqMc+50cDIJQpr6X0OHa4X58ULAw03QbRd7GUiG/K04mj0bNB xQhwJkEsJiZ1Bbgb6CnF79cBE+jwF91qniOCP3fghUFKxOShjIATw/wOfIQTg39LpFHtxhlKywAA AABJRU5ErkJggg== In-Reply-To: <848yraamxb.fsf@lucy.is.informatik.uni-duisburg.de> (Kai =?iso-8859-1?q?Gro=DFjohann's?= message of "Mon, 07 Jul 2003 08:08:48 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:53340 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:53340 On 7 jul 2003, kai.grossjohann@gmx.net wrote: > Gaute B Strokkenes 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?