Re: Decoding ISO8859-15 -- offending headers

[Simon Josefsson <jas@extundo.com>]

Daiki Ueno <ueno@unixuser.org> writes:

>>>>>> In <iluptwg2zlg.fsf@latte.josefsson.org> 
>>>>>>	Simon Josefsson <jas@extundo.com> wrote:
>
>> I think I found the patch.  I'll boot XEmacs to see what is breaking.
>> Masatoshi, do you remember the details?
>
>> 	* gnus-group.el (gnus-group-name-decode): Don't test
>> 	multibyte-string, because it breaks XEmacs.
>
> I should comment on this because I suggested him to remove the multibyte
> check.  And, for my real intention, I can't read any Japanese newsgroups
> whose names are encoded in UTF-8[1] without the patch.

Right, it seem to break my UTF-8 nntp groups too.

It also makes the .newsrc.eld contain different codings of the group
name depending on if I use Emacs or XEmacs.  Not good.

> I'll show you why the old group name encoder/decoder went wrong for
> both GNU Emacs and XEmacs-MULE.
>
> XEmacs-MULE: Without the patch, all the group names will be decoded
> twice because the current implementation of `mm-multibyte-string-p'
> for XEmacs is just an alias to `ignore'.  Unfortunately, we can't
> implement working multibyte-string-p for XEmacs-MULE because
> XEmacs-MULE uses a Latin-1 character so as to represent a byte in the
> range from 160 to 255.  See the last paragraph of
> "(internals)Character Sets" for details.
>
> GNU Emacs: nntp-server-buffer is marked as multibyte.  A string picked
> from the buffer is always regarded as multibyte, unless it doesn't
> contain a non-ASCII character.

Ok.  What would the solution be?  Make all the backends return
multibyte group strings?  Right now it seems nnfolder (and nnimap)
uses unibyte, and nntp uses multibyte, which won't work.