Marcus Harnisch <marcus.harnisch(a)gmx.net> writes:
[CC'd xemacs-beta]
Simon Josefsson <simon(a)josefsson.org> writes:
> Have you tried setting the imap-client-eol and/or imap-server-eol
> server variables?
I am using the nnimap backend, which doesn't seem to rely on imap.el.
Are you sure? All nnimap backends I've seen uses imap.el for IMAP
protocol parsing.
The interaction between various IMAP related packages and imap.el is
a
mystery that I have no intention to tackle.
FWIW, both variables are set to "\r\n".
Add them as server variables, like this:
(nnimap "foo"
(imap-server-eol "\n"))
or something like that.
No guarantees that this improves anything, but at least the EOL symbols
are configurable. The hard part is still to figure out which settings
are needed.
/Simon
Also, IMAP unrelated stuff breaks. `tls-end-of-info' (tls.el)
includes
hard coded EOL, which easy enough to fix in that one case, but you get
the idea.
Another observation shows that gnutls-cli appears to convert LF into
CRLF, even though the server sends CRLF terminated IMAP information
already.
,----
| 191 OK UID STORE completed^M^M
`----
Interesting that the TLS handshaking preamble sent by the server is
LF-only terminated. Gaah!
I tried tinkering with `process-coding-system-alist'[1] to no avail.
`default-process-coding-system' didn't seem to have an effect either.
Should a coding-system like "convert-eol-crlf" solve the issue?
Thanks
Marcus
Footnotes:
[1] Documentation issue: `process-coding-system-alist' claims
PATTERN were a program name, while #'start-process says that the
process name is used as key. Note the subtile difference.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta