Re: nnimap compatibility issues (UTF-7, msg count, SEARCH vs. group

[Dave Love <d.love@dl.ac.uk>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 2486 bytes --]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:

> Dave Love <d.love@dl.ac.uk> writes:
>
>>> 1. UTF-7 decoding mangled
>>>
>>> Here's the IMAP excerpt:
>>>
>>> 1 CAPABILITY
>>> * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ UIDPLUS X-NETSCAPE
>>> 1 OK Completed
>>> 2 LOGIN "hohohoimnottellingyou" "youdlovetoknow"
>>> 2 OK User logged in
>>> 3 LIST "" "*%"
>>> * LIST (\Noinferiors ) "/" "Trash"
>>> * LIST (\Noinferiors ) "/" "Unerw&APw-nscht"
>>> ...
>>> 3 OK Completed
>>>
>>> The "Unerw&APw-nscht" string is misdisplayed in the server buffer, it
>>> prints as "Unerw.ünscht";
>>
>> I'm not sure what that means and what exactly goes wrong.  Where is it
>> decoded from the utf-7?
>
> I don't know. Can you formulate a more specific question?

You said `misdisplayed in the server buffer', but in the text above
which appears to be from the server, it isn't decoded, and shouldn't
be.

>> Did this work before I changed utf7.el recently to cope with more than
>> Latin-1?  If so, it's probably a coding conversion confusion, and
>> perhaps the dot is a mangled \201 or similar.  Previously the decoder
>> returned a unibyte string, which doesn't make much sense.  As far as I
>> could tell, that just happened to work by automatic conversion (in a
>> Latin-1 session).  You could test it by commenting out
>> `mm-enable-multibyte' in `utf7-decode'.  I can't, I'm afraid.
>
> If I comment this one out, then the Unerw.*nscht folder disappears in
> the folder list when entering the buffer.

Do you mean it is still wrong?

> And yes indeed, the original
> buffer showed \201 before the other unprintable character.
>
> So somehow the character set the folder name was decoded to and the
> buffer/display's character set didn't match?

Something has decoded the multibyte text produced by the utf-7
decoding (i.e. it has been doubly decoded).  I assume this is in the
imap code, but I can't test that.

> But my bigger concern however is that I can't fetch messages from that
> server. See my previous mail.
>
> I can't really help myself out because my Elisp isn't even good enough
> to fully understand the code, and MULE isn't my strong point either.

I still don't know if it worked before I made changes to utf7.el.  Did
it work?  If so, I guess the change should be reverted until someone
can look at the imap code, but that means that mailbox names can only
be Latin-1 even when your Emacs can support more.