* test message: broken content-type & 8-bit messages
@ 1998-12-09 15:37 Vladimir Volovich
[not found] ` <5bk901z3lk.fsf@brandy.cs.rochester.edu>
0 siblings, 1 reply; 6+ messages in thread
From: Vladimir Volovich @ 1998-12-09 15:37 UTC (permalink / raw)
[-- Attachment #1: Type: text, Size: 480 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: test message: broken content-type & 8-bit messages
[not found] ` <m37lw1w16u.fsf@vvv.vsu.ru>
@ 1998-12-09 20:46 ` Shenghuo ZHU
1998-12-10 8:54 ` Vladimir Volovich
1998-12-10 18:27 ` Vladimir Volovich
0 siblings, 2 replies; 6+ messages in thread
From: Shenghuo ZHU @ 1998-12-09 20:46 UTC (permalink / raw)
>>>>> "VVV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes:
VVV> this did not help either. no changes; i see
VVV> \301\305\302... instead of russian chars in those broken
VVV> messages. note that when there is absolutely no content-type
VVV> header, gnus shows russian characters right (by default in
VVV> koi8-r). but i those message there was a content-type header, but
VVV> it was broken: it contained "text". in some earlier versions of
VVV> pgnus these messages were shown right.
You means there is "Content-type: text" in header? So you can see a
[1. text] button in *Article* buffer. Am I right?
If so, the content is not supposed to be decoded, since the minor type
of content is unknown. The mm-insert-inline is called instead of
mm-inline-text.
There is a trick to show the decoded content. Press 'i' on the button,
then 'C-u i koi8-r RET'.
There is a bug when you click the button 4 times. A patch is attached.
VVV> btw: from documentation on gnus-default-charset:
VVV> Default charset assumed to be used when viewing non-ASCII
VVV> characters. This variable is used only in non-Mule Emacsen.
VVV> but i do use mule (emacs 20.3 with mule).
The documentation is incorrect.
--
Shenghuo
ChangeLog:
Wed Dec 9 15:18:39 1998 Shenghuo ZHU <zsh@cs.rochester.edu>
* mm-decode.el (mm-display-part): Forward a line.
:- cut ----
--- mm-decode.el 1998/12/09 20:17:55 1.1
+++ mm-decode.el 1998/12/09 20:18:18
@@ -236,7 +236,8 @@
(if (eq user-method 'inline)
(progn
(forward-line 1)
- (mm-display-inline handle))
+ (mm-display-inline handle)
+ 'inline)
(when (or user-method
method
(not no-default))
@@ -244,6 +245,7 @@
(not method)
(equal "text" (car (split-string type))))
(progn
+ (forward-line 1)
(mm-insert-inline handle (mm-get-part handle))
'inline)
(mm-display-external
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: test message: broken content-type & 8-bit messages
1998-12-09 20:46 ` Shenghuo ZHU
@ 1998-12-10 8:54 ` Vladimir Volovich
1998-12-10 18:27 ` Vladimir Volovich
1 sibling, 0 replies; 6+ messages in thread
From: Vladimir Volovich @ 1998-12-10 8:54 UTC (permalink / raw)
"ZSH" == Shenghuo ZHU writes:
ZSH> You means there is "Content-type: text" in header?
yes.
ZSH> So you can see a [1. text] button in *Article* buffer. Am I
ZSH> right?
no, i cannot see such a button even if i use `M-t' or `K b' (at least
in nnmbox backend). [see my first message in this thread]
ZSH> If so, the content is not supposed to be decoded, since the
ZSH> minor type of content is unknown. The mm-insert-inline is called
ZSH> instead of mm-inline-text.
that's the whole point of rfc2047-default-charset and/or
gnus-default-charset? i.e. in the text messages with unspecified
charset or with broken syntax of c-t header or if 8-bit chars are
present while c-t claims that charset is us-ascii. or am i missing
something? gnus should treat 8-bit (non-ASCII) chars as encoded in
rfc2047-default-charset in such situations.
ZSH> There is a trick to show the decoded content. Press 'i' on the
ZSH> button, then 'C-u i koi8-r RET'.
i do not see a button, --- see my first message in this thread.
VVV> btw: from documentation on gnus-default-charset: Default charset
VVV> assumed to be used when viewing non-ASCII characters. This
VVV> variable is used only in non-Mule Emacsen. but i do use mule
VVV> (emacs 20.3 with mule).
ZSH> The documentation is incorrect.
then, what is the difference betweem rfc2047-default-charset and
gnus-default-charset? both are defined in gnus...
Best regards, -- Vladimir.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: test message: broken content-type & 8-bit messages
1998-12-09 20:46 ` Shenghuo ZHU
1998-12-10 8:54 ` Vladimir Volovich
@ 1998-12-10 18:27 ` Vladimir Volovich
1998-12-10 20:31 ` Michael Welsh Duggan
1 sibling, 1 reply; 6+ messages in thread
From: Vladimir Volovich @ 1998-12-10 18:27 UTC (permalink / raw)
"ZSH" == Shenghuo ZHU writes:
ZSH> There is a trick to show the decoded content. Press 'i' on the
ZSH> button, then 'C-u i koi8-r RET'.
btw, it would be nice to be able to force decoding for a given charset
for a non-multipart messages, too (in cases when charset was specified
incorrectly by a broken MUA). [for non-multipart messages there are no
buttons, and `i' is not working]
Best regards, -- Vladimir.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: test message: broken content-type & 8-bit messages
1998-12-10 18:27 ` Vladimir Volovich
@ 1998-12-10 20:31 ` Michael Welsh Duggan
1998-12-10 20:57 ` Vladimir Volovich
0 siblings, 1 reply; 6+ messages in thread
From: Michael Welsh Duggan @ 1998-12-10 20:31 UTC (permalink / raw)
Vladimir Volovich <vvv@vvv.vsu.ru> writes:
> "ZSH" == Shenghuo ZHU writes:
>
> ZSH> There is a trick to show the decoded content. Press 'i' on the
> ZSH> button, then 'C-u i koi8-r RET'.
>
> btw, it would be nice to be able to force decoding for a given charset
> for a non-multipart messages, too (in cases when charset was specified
> incorrectly by a broken MUA). [for non-multipart messages there are no
> buttons, and `i' is not working]
`C-u W M c' doesn't work?
--
Michael Duggan
(md5i@cs.cmu.edu)
.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: test message: broken content-type & 8-bit messages
1998-12-10 20:31 ` Michael Welsh Duggan
@ 1998-12-10 20:57 ` Vladimir Volovich
0 siblings, 0 replies; 6+ messages in thread
From: Vladimir Volovich @ 1998-12-10 20:57 UTC (permalink / raw)
"MWD" == Michael Welsh Duggan writes:
>> btw, it would be nice to be able to force decoding for a given
>> charset for a non-multipart messages, too (in cases when charset
>> was specified incorrectly by a broken MUA). [for non-multipart
>> messages there are no buttons, and `i' is not working]
MWD> `C-u W M c' doesn't work?
Hmm [i did not know about `W M c']. Here is what i get:
* if the article is already decoded (maybe, wrongly), then pressing
`C-u W M c' and specifying another charset causes buggy
double-decoding (resulting in \214<8-bit-char> mess)
* to deal with the above [is it a bug?] i can do `C-u g' an article
before pressing `C-u W M c'.
* and most important, this does not work for the article which started
this thread: pressing `C-u W M c' and specifying any charset has no
effect at all --- an article remains unencoded (i.e. looks like
`\301\305\302...'). this is perhaps a bug.
Best regards, -- Vladimir.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1998-12-10 20:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-12-09 15:37 test message: broken content-type & 8-bit messages Vladimir Volovich
[not found] ` <5bk901z3lk.fsf@brandy.cs.rochester.edu>
[not found] ` <m367blnp7x.fsf@vvv.vsu.ru>
[not found] ` <5b90ghf956.fsf@brandy.cs.rochester.edu>
[not found] ` <m37lw1w16u.fsf@vvv.vsu.ru>
1998-12-09 20:46 ` Shenghuo ZHU
1998-12-10 8:54 ` Vladimir Volovich
1998-12-10 18:27 ` Vladimir Volovich
1998-12-10 20:31 ` Michael Welsh Duggan
1998-12-10 20:57 ` Vladimir Volovich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).