* 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
[parent not found: <5bk901z3lk.fsf@brandy.cs.rochester.edu>]
[parent not found: <m367blnp7x.fsf@vvv.vsu.ru>]
[parent not found: <5b90ghf956.fsf@brandy.cs.rochester.edu>]
[parent not found: <m37lw1w16u.fsf@vvv.vsu.ru>]
* 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).