bug#5046: Too silent error reporting in imap.el:imap-open-1

[nisse@lysator.liu.se.?= (Niels =?UTF-8?Q?M=C3=B6ller)]

This is a problem that I experienced on emacs-22.3 on w*ndows, but the
code in question seem to be identical in emacs-23.

I tried to configure an nnimap server in Gnus, and connection failed,
with a message

  imap: Connecting to the-mail-server.com...failed

with no further details. The real error was hidden by the
condition-case

    (setq imap-current-mailbox nil
	  imap-current-message nil
	  imap-state 'initial
	  imap-process (condition-case ()
			   (funcall (nth 2 (assq imap-stream
						 imap-stream-alist))
				    "imap" buffer imap-server imap-port)
			 ((error quit) nil)))

in imap.el:imap-open-1.

After some debugging, involving adding some additional message calls
in imap-open-1, I figured out the trivial source for the problem. A
typo in my .gnus file, where I wrote

  nnimap-stream 'tls

rather than

  nnimap-stream tls

Now, (quote tls) is not present on the imap-stream alist, which
results in an attempt to funcall nil.

If I had received an error message like "(quote tls) is not a valid
imap stream type", I would have solved the problem a lot quicker.

I'd like to suggest that error reporting is improved as follows:

1. Messages of the form "Connecting to <some host>... failed." should
   be used only when the actual problem is related to the network
   connection (dns errors, connection refused, possibly tls-related
   handshaking errors, etc). It's long time since I read the elisp
   documentation, so I'm not sure if there are some defined error
   symbols that make this case easy to distinguish from other errors.
   And in the case that the error is in fact network related, it would
   be helpful to have the message provide any details that are
   available, to aid investigation of the underlying networking
   problem.

2. When imap-stream is not found on the imap-stream-alist, this should
   either be reported in some human-friendly form, or it should raise
   an error which is not masked by condition case on the way up. This
   would typically indicate either a configuration error (like in my
   case), or a bug in whatever code using imap-open. If I had seen the
   void-function error for this particular funcall, that would also
   have pointed out the problem fairly accurately.

3. The data for the error should not be throuwn away. If nothing more
   sensibly can be done to it, even a crude change to

	  imap-process (condition-case (e)
			   (funcall (nth 2 (assq imap-stream
						 imap-stream-alist))
				    "imap" buffer imap-server imap-port)
			 ((quit) nil)
			 ((error) (message "imap-open: unexpected error %s" e) nil)))

   would be an improvement.

Regards,
/Niels