[T] support EMIKO 1.14

[Katsumi Yamaoka]

>>>>> In [emacs-mime-ja : No.00945]
>>>>>	Daiki Ueno <ueno ＠ unixuser.org> wrote:

上野さん> たぶん山岡さんは、このような代替案はあらかた考慮されていると
上野さん> 思いますが、

考えてませんて。この問題の対策を行なうのはたぶんこれで三回目です
が、その都度何が起こっているかを調べ直しているザマですから。:-p

上野さん> mime-edit-invisible を付加することにした時の記憶が既におぼろ
上野さん> げなので、もう一度 T-gnus の message.el を眺めてみたのですが、

ぼくも自分の鶏頭にしっかり刷り込むために、考えながらコメントして
みます。実はあんな変なことはやらなくても良いのではないかと思い始
めています。

上野さん> (1) EMIKO 以外の SEMI は `invisible-region' を使って付加した
上野さん> invisible プロパティをパートの境界を判断するのに利用している。

そうですね。そして、エンコードするときに invisible な領域の直後
に MIME tag 以外のものがあったら text の tag を挿入するのは少な
くとも後期の tm では行なわれていますから、これは伝統と言っても良
さそうです。

一方 tm をかなりお手本にしたと思われる v5.8 以降の Gnus では tag
の文字列が情報のすべてであって、SEMI のように binary データの実
体を人間が編集するバッファに挿入しない代わりに、binary データの
tag を挿入した場所の先に何も無くても text の tag を必ず付けます。
揮発性の高い text property に依存しないこの方法も、ぼくは確実で
良いと思っています。

上野さん> (2) message.el 内で `invisible-region' を 
上野さん> `message-invisible-region' に置き換えて、特定の領域からは
上野さん> invisible プロパティを剥ぎ取らないように、message-invisible
上野さん> プロパティで印をつけている。

はい。この関数の置き換えは、後々何をやっているのか忘れてしまいそ
うで心配だったのですが、案の定でありました。^^;;

Semi-gnus の良いところは、人間が編集するバッファとエンコードする
バッファが別になっていることで、万が一送信に失敗しても最初から書
き直したりエンコードによる変更を undo する必要がありません。

でも Gnus は message の処理のいろんな区切り目に (undo-boundary)
を入れてあるので、T-gnus でも同様のことができるような気がします。
あるいはエンコードするときは元のバッファの内容を別の場所にコピー
して保存するようにしても良いわけですし。

そして次が問題なのですが、編集用のバッファからエンコード用のバッ
ファに内容物をコピーするときに、T-gnus では Gnus の
message-send-mail に倣ってすべての text-property をはぎ取ってい
ます。ただし invisible または mime-edit-invisible は残します。

上野さん> (3) EMIKO は `message-invisible-region' 相当のものを自前で用
上野さん> 意しているため、(1) (2) が効かなかった。

はいそうです。昨日までの T-gnus では mime-edit-invisible を消し
てしまっていました。

どうもぼくは何も考えずに Gnus をデッドコピーしたのではないかと思
うのですが、T-gnus ではすべての text-property をはぎ取る必要は無
かったのではないか。もしそうならば、これをやめることによって問題
の 70% は消えてしまいます。Chaos を覗いてみると実際にそんなこと
はしていませんし。

上野さん> * `message-send' で、テキストプロパティを一切剥ぎ取らない。
上野さん> → X-Face utility などとの兼ね合いから、これでは悲しいことに
上野さん> なる?

X-Face util?  はて、自分では何も思い出せないので、ともかく実験が
必要ですね。^^;;

上野さん> * `gnus-copy-article-buffer' を変更して、*Article* バッファ
上野さん> からコピーする時点で、(2) のアプローチとは逆に invisible プ
上野さん> ロパティを剥ぎ取っても良い領域に message-invisible プロパティ
上野さん> を付加する。

うーむ、これもわからんぞ。article から持ってきたものを MIME-Edit
でエンコードするのって、どういうときでしたっけ? ^^;;
message バッファからエンコード用のバッファに移すときにそうするの
は良いでしょうね。

前に 70% と書きました。残りの 30% は何かというと、T-gnus には
(Gnus にも) 人間が編集するバッファに不可視なものがあったら、
「こんなものがあるけど、このまま送信しちゃっていいの?」とユーザ
に見せてお伺いをたてる機能があります。ここで MIME-Edit が挿入し
たデータも対象になってしまうのは煩わしいので、現在はチェックする
ときだけ invisible を解除していて、その判別に
mime-edit-invisible ないしは mime-edit-invisible の印が必要です。

たいした違いではないですが、そういう印が付いていたらチェック対象
にならないようにすることも可能でしょう。

上野さん> * `x-face-mule-hidden-properties' 相当の変数を EMIKO に用意
上野さん> する。
上野さん> ;; `mime-edit-invisible' という名前は、あまりにもあん
上野さん> ;; まりなので…。

ではどんな名前が良いでしょう? :-)
すでに普及している EMIKO との互換性を保つためには、このままにし
ておくのが良いような気もしますが。と言うのは、

ここまで書いて思い付いた今後の方針:

・副作用が無いならば、編集用のバッファからエンコード用のバッファ
  にコピーするときに一切の text property をはぎ取らない。

・mime-edit-invisible が付いている部分は不可視領域のチェック対象
  から外す。

・invisible-region を置き換える関数 message-invisible-region が
  付加する property は、現在の message-invisible に代わって
  mime-edit-invisible とする。

といったところでいかがでしょうか?
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>
;; すみません、長くて。^^;;