Re: Problem with imap.el under Windows

[Nathaniel Calloway]

Jason Rumney <jasonrumney@gmail.com> writes:

Thanks so much for your help! You've been the most helpful of anyone
I've asked yet.

> While C-x b *test* C-: (start-process "test" "*test*" "gnutls-cli" "-
> p" "993" "IMAP-SERVER") is missing the last line, and if you
> subsequently do (process-send-string "test" "1 CAPABILITY"), the "* OK
> Dovecot ready" line appears, but the output of the capability command
> does not appear until you issue another command.  Even (process-send-
> string "test" "2 LOGOUT") does not appear to terminate the process
> until you give it another line of output.

Well, crud. Windows was the culprit, it appears. I have replicated the
above, and figured out that this is indeed the problem with the
functions I mentioned.

> Besides that, Gnus forces the process encoding to binary, so it picks
> up all the ^M characters from the server (most internet protocols use
> CRLF line ends), but the buffer into which it puts the output does not
> have an encoding specified, so it will be created with the default
> line-end convention for the platform. Effectively this means that on
> Windows, depending on how the information is subsequently read from
> that buffer by Gnus, you may end up with a double ^M^M at the end of
> each line, which might cause problems somewhere.  I can't get far
> enough through to see if this is really a problem, but it might
> explain why all the methods that involve external programs have
> problems, not just ones that use the broken gnutls-cli.

All the other external programs have the same problem. They are all
waiting for the "OK IMAP server ready" message, so they check once a
second for enternity. Faking a connection and sending the messages
with ^M's back into imap.el didn't cause any problems...yet.


Well, this seems hackable, but do you have any insight into
ways arround this. I will give it a try nonetheless.

Thanks again,

-Nat