From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/52840 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap compatibility issues (UTF-7, msg count, SEARCH vs. group Date: Sun, 25 May 2003 17:47:23 +0100 Sender: ding-owner@lists.math.uh.edu Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1053881148 4090 80.91.224.249 (25 May 2003 16:45:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 25 May 2003 16:45:48 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M1384@lists.math.uh.edu Sun May 25 18:45:45 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19Jycz-00013E-00 for ; Sun, 25 May 2003 18:45:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19Jyeq-0004rO-00; Sun, 25 May 2003 11:47:40 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19Jyel-0004rJ-00 for ding@lists.math.uh.edu; Sun, 25 May 2003 11:47:35 -0500 Original-Received: (qmail 23364 invoked by alias); 25 May 2003 16:47:34 -0000 Original-Received: (qmail 23359 invoked from network); 25 May 2003 16:47:34 -0000 Original-Received: from albion.dl.ac.uk (148.79.80.39) by sclp3.sclp.com with SMTP; 25 May 2003 16:47:34 -0000 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.36 #1 (Debian)) id 19JyeZ-0006nH-00; Sun, 25 May 2003 17:47:23 +0100 Original-To: Matthias Andree In-Reply-To: (Matthias Andree's message of "Fri, 23 May 2003 19:59:39 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:52840 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:52840 Matthias Andree writes: > Dave Love 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.=FCnscht"; >> >> 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.