Unabhle to read group descriptions

[Simon Josefsson]

Hrvoje Niksic <hni...@arsdigita.com> writes:

> I pressed `H d' in the Group buffer to get the description of the
> group under point. Emacs read a lot of data through NNTP (the whole
> active file?) and spent several minutes parsing it. Then it signaled
> the following error:
>
> No such coding system: vietnamese-viqr
>
> When I retry pressing `H d', I get the correct description. What
> gives?

This probably depends on what the server responds, is it a public
server?

Maybe you can look in " *nntpd*" to see if it contains some funny
characters.

Anyway, I don't think there should be any Mule stuff going on for
descriptions unless `gnus-group-name-charset-method-alist' or
`gnus-group-name-charset-group-alist' indicate this.

[Hrvoje Niksic]

Simon Josefsson <j...@extundo.com> writes:

> Hrvoje Niksic <hni...@arsdigita.com> writes:
>
>> I pressed `H d' in the Group buffer to get the description of the
>> group under point. Emacs read a lot of data through NNTP (the whole
>> active file?) and spent several minutes parsing it. Then it signaled
>> the following error:
>>
>> No such coding system: vietnamese-viqr
>>
>> When I retry pressing `H d', I get the correct description. What
>> gives?
>
> This probably depends on what the server responds, is it a public
> server?

It is. The whole point of the bug is that Gnus shouldn't react badly
on "funny" characters sent by the server. I don't think NNTP uses ISO
2022, or whatever Mule thinks it understands.

[Simon Josefsson]

Hrvoje Niksic <hni...@arsdigita.com> writes:

Right. There seems to be some thinking about this, by the look of the
code -- the buffer should be in unibyte, and the Mule functions are
called on each string as needed. Do you have the whole backtrace?

(OTOH, assuming that vietnamese-viqr is something ISO 2022 related,
this might be the emacs bug where it honors ISO 2022 escape codes even
when in unibyte-everything-disabled mode.)

[Hrvoje Niksic]

Simon Josefsson <j...@extundo.com> writes:

> Right. There seems to be some thinking about this, by the look of the
> code -- the buffer should be in unibyte,

That kind of code is often broken under XEmacs/Mule. There is no such
thing as a "unibyte" buffer or string in XEmacs. You just have to
tell Mule not to interpret stuff it receives as ISO 2022 or whatever.

> (OTOH, assuming that vietnamese-viqr is something ISO 2022 related,
> this might be the emacs bug where it honors ISO 2022 escape codes
> even when in unibyte-everything-disabled mode.)

I'm using XEmacs.