Re: Problem with imap.el under Windows

[Jason Rumney]

On Apr 15, 10:24 pm, Nathaniel Calloway <n...@cornell.edu> wrote:

> Using imap-tls-open as an example:
>
> Running imap-tls-open locks up emacs, but the function (used inu
> imap-tls-open) open-tls-stream works just fine, and starts a working
> tls connection from within emacs. The same is true of the other
> protocols.
>
> THEREFORE, it is my guess that there is something in common to these
> imap.el functions that is breaking emacs.

In the case of gnutls-cli, there seems to be some buffering of output
going on that prevents it being useful as a subprocess, at least in
the latest official Windows build. This is a common problem in Windows
command-line programs, as the default behaviour of the system
libraries changes depending on whether you are running in an
interactive terminal or pipe, so if you don't explicitly flush stdout,
you can never be sure that the output has gone into the pipe.  To
demonstrate, from the command line, "gnutls-cli -p 993 IMAP-SERVER"
outputs:
    ....
    - Handshake was completed

    - Simple Client Mode:

    * OK Dovecot ready.

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.

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.