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

[Ramkumar R <andyetitmoves@gmail.com>]

> 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..

> 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.

Regards,
Ramkumar.

-- 
The day Microsoft makes something that doesn't suck
is probably the day they start making vacuum cleaners.
                                               -Ernst Jan Plugge