jka-compr (Re: semi-vm-6.75-20000529)

[Katsumi Yamaoka]

>>>>> In [apel-ja : No.00383] 
>>>>>	Shuhei KOBAYASHI <shuhei ＠ aqua.ocn.ne.jp> wrote:

山岡> ことの是非はともかく、これと対になる(?) `write-region-as-binary' 
山岡> も jka-compr を抑制するのは許すとして、
山岡> `write-region-as-coding-system' もそうする必然性は無いような気が
山岡> します。

小林さん> (write-region-as-coding-system 'binary ...) と
小林さん> (write-region-as-binary ...) の動作が異なっても構わないと
小林さん> 思いますか?

うう〜む、気持ち悪いです。(^^;;)
昨日ぼくが semi-vm-6.75-20000529 で行なった変更は、vm-write-region-as-
(coding-system|binary) という、どちらも jka-compr の動作を抑制しない関
数 (macro) を使って、圧縮された VM のフォルダを読み書きできるようにす
るための、いささか苦し紛れの対応でした。

小林さん> jka-compr を抑制する必要がありそうなのは coding-system が 
小林さん> binary か,せいぜい raw-text の時くらいなので, *-as-binary と 
小林さん> *-as-raw-text 系のみ jka-compr や jam-zcat を抑制し,
小林さん> *-as-coding-system ではこれらを抑制しないということに決めて
小林さん> しまうのがよいのかもしれません.

気持ち悪いと言うのはぼくの勝手で、確かにそれが現状では最も穏便な対応だ
と思います。しかしそれはたまたま現存するアプリケーションに対応するだけ
のことですよね。coding-system を決め打ちにしてファイルの読み書きを行な
う機会に比べて、jka-compr の ON/OFF を意識しなければならない機会はずっ
と少ないのではないでしょうか。
例えばメールのファイルを Emacs が読み書きするときは binary で行なう場
合が多いわけですが、ここで jka-compr を抑制していなければ可能性が広が
ります。(gnus などの現実はそう甘くないですが。^^;;)

小林さん> find-file-noselect と save-buffer も jka-compr や jam-zcat 
小林さん> を抑制する必要はないのではないかと思っていますがどうでしょう
小林さん> か?

はい、それも良いと思います。

ぼくが最も美しいのではないかと思ったのは、jka-compr や jam-zcat の有無
に関わらず、各アプリケーションプログラムが必要に応じて圧縮伸長を自前で
やるというものでした。既存のものをそういうふうに直すのは大変ですが、新
規に作るプログラムの場合には考慮しても良いのではないでしょうか。
というのは (それこそ機会は少ないかもしれませんが) ユーザが M-x
toggle-auto-compression を使う度にプログラムの動作が変わってしまうのも
変ですから。

ともあれ、一番気持ちが悪いのは現在の APEL なので (^^;;)、他のみなさん
のご意見も聞きたいです。何なら投票で方針を決めましょう。

小林さん> [2 pces-20.el <application/octet-stream (7bit)> ...]
小林さん> 参考: X-Mail-Count: 00221

すっきりしていて良いですね。また、仕様を統一するにも便利そう。:-)
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>