Re: Fwd: Patch for a bug in imap-open

[Simon Josefsson <jas@extundo.com>]

Ramkumar R <andyetitmoves@gmail.com> 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.