bytes vs. characters problem (Re: [emy] mime-display-gzipped)

[Yoshiki Hayashi]

ari ＠ atesoft.advantest.co.jp (Akihiro Arisawa) writes:

> >>>>> In [emacs-mime-ja : No.00496] 
> >>>>>	tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:
> 
> 有沢>         T-gnus (6.14.1 r12)
> 有沢>         RMAIL-MIME (1.13.0)
> 有沢>         mime-edit-preview-message
> 寺西> 有沢さんが示された下の 3 つは、
> 寺西> raw-buffer が multibyte になっていると思われるので、
> 寺西> これらの方を直すのが正しい気がします。
> 守岡> そうですね。
> 
> T-gnus, RMAIL-MIME 共に以下のように変更し、mime-display-gzipped を
> [emacs-mime-ja : No.00495] のようにしたところ、問題なく表示できました。

今の CVS 版の EMY の code で、T-gnus の変更無しでも動くと思
うのですが、有沢さんのところでも動きますよね。
# 新しい方にしたら、という話だと思うけど、念のため。(^^;

寺西さんが書かれたものの方がすっきりとしていて、Right Thing 
を実行していますが、EMY 側では最新の MUA に update すること
を要求したくはないので、今の code のままにしようと思います。

ちょっと試してみたところでは、FSF Emacs では、internal code
の byte sequence が見えかくれして嫌な感じなのですが、
decode-coding-region も動いているようにみえます。source code 
は見てないので想像ですが、buffer を multibyte にしたときに、
internal code に存在する byte sequence は文字に変換されてし
まうようですが、decode-coding-region は文字の internal code 
の byte sequence を使うようなので動作するようです。

FSF Emacs 上ではかなり気持悪いことになっていますが、とりあえ
ず動けば良いことにしておきます。:-)
# 山岡さんが書かれていた問題そのものだけど、FSF Emacs では普
# 通に string を処理しているときに、current buffer の 
# multibyte-ness で結果が変わるのだけはどうしても耐えられな
# い。寺西さんの code でも、間違って decode-coding-string を
# with-temp-buffer の中に書くと、^[$B とかになるし。
;; Emacs/Mule is broken. :-)

-- 
Yoshiki Hayashi