[emy] mime-display-gzipped

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> [emacs-mime-ja : No.00491] にて
>>>>> “Yoshiki”= Yoshiki Hayashi <yoshiki ＠ xemacs.org> さま曰く:

Yoshiki> 寺西さんの patch を FLIM 1.13.2 に当ててしまおうと思っていま
Yoshiki> すが、その後で FLIM 1.13.3 を release して頂きたいです。どう
Yoshiki> でしょう、守岡さん。

保留します。

寺西さんの patch というのが良く判っていないのですが、
<emacs-mime-ja:00488> のことであれば、これ自体は問題ない気もするんです
が、後述するように若干不安要因があります。また、これで直るのだとすると
問題は MEL 層に関連している可能性があり、原因を究明して直したとは言え
ないと思います。

もし、抜本的に直すのなら、mime-entity-content の返り値は unibyte 文字
列であることを明示するような修正が良いと思います。


また、EMY 1.13 の mime-display-gzipped を眺めてみましたが、この code 
は原理的な問題を抱えている気がします。まず、mime-entity-content の返り
値を挿入する temporary-buffer は byte 列ですから unibyte buffer を用意
する必要があります。これの実現の仕方はちょっとうげげではあるんですが、

(let (default-enable-multibyte-characters)
  (with-temp-buffer
    ...)

か  

(with-temp-buffer
  (set-buffer-multibyte nil)
  ...)

見たいな感じでしょうか？

gzip での処理は byte 列の処理ですから unibyte として扱うのが正しいと思
います。

で、問題は decode-coding-region で、これは入力は byte 列、出力は文字列
のような処理だと考えられますが、単一の buffer では byte と文字の見分け
はつかないので、両者の混在状態を作ってしまう decode-coding-region の使
用は望ましくないです。特に、この関数では decode-coding-region を用いる
必然性は全くないと思います。この場合、decode-coding-string を使った方
が無難でしょう。

;; [補足] FLIM/SEMI の世界では以下のことが期待されています：

;; ・整数と文字は違う抽象型として区別する
;; ・byte 列と文字列は違う抽象型として区別する
;; ・byte 列は unibyte で表現する
;; ・文字列は unibyte/multibyte のどちらかを取り得る
;; ・STD 11 の世界は byte 列として解釈する

;;; もちろん、FLIM/SEMI 自体がこの観点から見ておかしい可能性があります
;;; が、その場合は扱っているのが byte 列なのか文字列なのかを判断して適
;;; 切に修正するのが望ましいと思います。


Yoshiki> > ということで、mmbuffer.el の `mime-entity-content' を同様に
Yoshiki> > してみたところ、前述の全てのMUA で問題無く表示できました:-)

Yoshiki> なるほど、今の FLIM の実装だと raw buffer の
Yoshiki> enable-multibyte-characters の値を引き継ぐので、insert 時に
Yoshiki> その buffer で同じ値でないと各 representation に変換されてし
Yoshiki> まうわけですね。

Emacs は文字列を「byte 列」ではなく「文字列」として解釈します。一方、
`mime-entity-content' の返り値は「byte 列」です。よって、意味的には
unibyte 文字列であることが望ましいと言えます。

;; raw-buffer は MUA が unibyte buffer にしているはずなので、MEL が変
;; なことをしてなければ返り値も unibyte になることが期待できる訳です。

また、preview buffer のような概念的に文字列であるところに 
`mime-entity-content' の返り値を挿入するのは誤った操作であると考えられ
ます。


Yoshiki> 寺西さんの patch を当てると、temp buffer と
Yoshiki> enable-multibyte-characters の値が常に同じになるので大丈夫で
Yoshiki> ある、と。

新たに生成される buffer が unibyte か multibyte かを決めるのは変数 
default-enable-multibyte-characters で、<emacs-mime-ja:00488> はこのこ
とを保証していないと思います。また、FLIM 的には multibyte 表現を返すの
はおかしいと言えます。いずれにしてもこの修正が効果を持つのだとすればな
にやら良からぬことが起こっていると考えられます。


という訳で、再検討をお願いします。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
======================================== Email: <tomo ＠ etl.go.jp> =====