From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/60821 Path: news.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: Fwd: Patch for a bug in imap-open Date: Sun, 28 Aug 2005 11:12:06 +0200 Message-ID: References: <9a9bfc1705082505035774a0e0@mail.gmail.com> <9a9bfc1705082613105b0a87f1@mail.gmail.com> <9a9bfc170508270705c0af282@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1125220409 19064 80.91.229.2 (28 Aug 2005 09:13:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 28 Aug 2005 09:13:29 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M9353=ding+2Daccount=gmane.org@lists.math.uh.edu Sun Aug 28 11:13:27 2005 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by ciao.gmane.org with esmtp (Exim 4.43) id 1E9JDM-0002aw-Pw for ding-account@gmane.org; Sun, 28 Aug 2005 11:12:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1E9JDL-00011i-00 for ding-account@gmane.org; Sun, 28 Aug 2005 04:12:31 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1E9JD8-00011Z-00 for ding@lists.math.uh.edu; Sun, 28 Aug 2005 04:12:18 -0500 Original-Received: from quimby.gnus.org ([80.91.224.244]) by util2.math.uh.edu with esmtp (Exim 4.30) id 1E9JD7-0008Fl-NX for ding@lists.math.uh.edu; Sun, 28 Aug 2005 04:12:17 -0500 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1E9JD4-0004Qe-00 for ; Sun, 28 Aug 2005 11:12:14 +0200 Original-Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j7S9C9cq022289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 28 Aug 2005 11:12:10 +0200 Original-To: Ramkumar R OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050828:ding@gnus.org::P99+9EP/ImozAriC:0q5U X-Hashcash: 1:21:050828:andyetitmoves@gmail.com::ATfrGstamEuneHCz:IsSe In-Reply-To: <9a9bfc170508270705c0af282@mail.gmail.com> (Ramkumar R.'s message of "Sat, 27 Aug 2005 19:35:47 +0530") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=failed version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: -4.9 (----) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: news.gmane.org gmane.emacs.gnus.general:60821 Archived-At: Ramkumar R writes: >> There is something wrong with this patch; imap-open should make sure >> the returned process is inside the buffer provided in the BUFFER >> argument. Your patch changes this interface, causing all callers of >> imap-open to be updated as follows: > > yeah....i realised that. from what i could gather from the function, > the function tries to create a new buffer when tls is supported and > fills in the contents. If we have to use the same buffer, we would > need to reinitialize the buffer to a clean state, and use it instead > of a new buffer. as i said, i am not familiar with the gnus > source...so i didn't know if copying buffer contents after possibly a > kill-all-local-variables would be safe...(the older buffer also has a > process) or is it required that we selectively tweak some > variables....this seemed the easiest way out...if u can figure that > out, then perhaps we can manage with the same buffer.. But doing that is exactly what the current code attempts to do. It create a temporary buffer for the TLS/GSSAPI/whatever, and if that connection succeed, it close the first connection (in BUFFER), kill that buffer and rename the new temporary buffer to the old BUFFER: (message "imap: Reconnecting with stream `%s'..." stream) (if (null (let ((imap-stream stream)) (imap-open-1 (current-buffer)))) (progn (kill-buffer (current-buffer)) (message "imap: Reconnecting with stream `%s'...failed" stream)) ;; We're done, kill the first connection (imap-close buffer) (kill-buffer buffer) (rename-buffer buffer) (message "imap: Reconnecting with stream `%s'...done" stream) >> Exactly what problem did you see? Use (setq debug-on-signal t) to >> find errors that are swallowed by condition-case. > > well...debug-on-signal springs up a lot of other spurious errors in > other packages in my setup. For that matter, there are many cases > where condition-case's are genuine, unlike in the case i described, > where it was an error which was covered up for the user's convenience. You can press `c' to continue passed spurious errors. I think we should go back to what your original problem was instead of looking at possible solutions. I haven't understood what problem you want to solve.