binary-start-process

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> In [emacs-mime-ja : No.00762] 
>>>>>	"Daiki" = Daiki Ueno <ueno ＠ bug.org> wrote:

守岡> (d) emacsen の process 実装上の trick を用いることは避けること

守岡> だったのですが、(d) は私の誤解です。虫を入れてしまってすみません。

守岡> これも事実誤認ですね。実際には pces の実装上の trick を使って、
守岡> 仕様外の使い方をしてたのが問題だったといえると思います。

守岡> いずれにしても、すみませんでした。

Daiki> 個人的には、例えば、

Daiki> binary-input-start-process
Daiki> binary-output-start-process

Daiki> binary-input-start-process-shell-command
Daiki> binary-output-start-process-shell-command

Daiki> binary-input-open-network-stream
Daiki> binary-output-open-network-stream

Daiki> のような variant を用意することなく、制御できる枠組があると嬉し
Daiki> いのですが。

全く持って同感です。

個人的には、将来、型付き stream と多層 chunk object model に基づく、入
出力、および、データ表現に関する抽象を実現し、file, process, network,
buffer, region, 文字列、vector 等を透過的に扱えるようにするのは、是非、
取り組みたいテーマの１つです。

でも、それは今回の FLIM/SEMI project の課題ではなくて、UTF-2000
project（ないしは、その後継 project）の課題だと思っています。そういう
訳で、是非 UTF-2000 project でも活発に御参加頂けたら幸いです。

とりあえず、macro は良くないと思うし、coding-system-for-{read|write}
を囲むというのも特定の Mule 実装の構成法に依存するので、良くない方法だ
と思います。

（少なくとも私にとっての）FLIM では、byte 列と文字列は違う抽象型です。
文字列とは違う型のものを入出力するなら、文字列用の入出力とは違うことを
明示するのが良いと思います。しかし、今の Mule API には汎用の入出力機構
はなく（私と半田さんらで、個人的には、将来構想として議論していますが）、
いわば文字列と coding-system や、unibyte/multibyte, その他 ad-hoc な方
法でごまかしているのが現状です。とはいえ、データ抽象を愛するものとして
は、byte 列と文字列は違うことを弁え、できるだけそれを明示すべく記述す
るのが良いと思います。

また、敢えて、binary-* のような専用の関数を設けることの利点を述べるな
ら、将来、入出力での変換の制御のためのより良い汎用の機構ができた時にも
容易に実装できそうだという可能性が高そうだということもあると思います。
let で囲む方法ではこの点が困難だと思います。まあ、そんな将来のことなん
て知ったことではないとは思いますが。


守岡> language-info-alist は何でもありですから、適当な機構を PGG が提
守岡> 供することにより、それを使った設定を set-language-environment と
守岡> 同期して行うことは可能です。

Daiki> これは必要なのでしょうか？

判りませんが、やろうと思ったらかなり何でもできるということを言っている
だけです。

Daiki> coding-system-for-read を束縛せずに start-process を呼んだとき
Daiki> に、Emacsの automatic conversion がうまくいかない言語環境が存在
Daiki> する、ということでしょうか？

守岡> すみません。これはどこにあるんでしょうか？現在の公的開発枝である 
守岡> semi-1_14にはないようですが。

Daiki> emiko-1_14 にあります。

了解しました。


守岡> あと、私の強い希望は上記を作ることではなく、下記の

守岡> あと、これもしくはそれ以外の手段を使って、命令 
守岡> `set-language-environment' and/or 変数 
守岡> `current-language-environment' と同期する形で適切に PGG の表示を
守岡> 設定することは可能でしょうか？

Daiki> 「current-language-environment と同期する形で PGG の表示を設定
Daiki> する」とは、

Daiki> $ LANG=C emacs

Daiki> M-x set-language-environment Japanese

Daiki> としたときに、依然 process-environment には LANG=C が含まれたま
Daiki> ま gpg が呼ばれてしまうので、これを制御する、ということでしょう
Daiki> か？

はい。できればそうした方が良いでしょうね。


Daiki> そうであるとすると、pgg-messages-locale を新設し、
Daiki> (set|get)-language-info によりこれを制御すれば良いのではないか
Daiki> と思います。

良いんじゃないかと思います。

Daiki> ;; しかしながら、この場合、override すべき LC_MESSAGES には単に 
Daiki> ;; "ja" のような言語コードを設定するだけで良いのでしょうか。ま
Daiki> ;; た、Emacs21 ではsystem-messsages-locale が用意されていますが、
Daiki> ;; set-language-environmentしただけでは、system-messages-locale 
Daiki> ;; は設定されません。これは何を意味するのでしょうか？

良くは把握してないのですが、原理的に考えれば、言語というのは nest する
と思うので、大本の emacs 全体の locale が必要なのは当然だと思います。
これにかぶさる形で、buffer の言語があり、buffer 内の文書の中でまた別の
言語の文や単語を引用してたり含んでたりするというような階層構造になると
思います。

;; ただ、現在の Emacs 21 ないしは Mule 実装を根拠にするのは甚だ危うい
;; と思います。ご存知のように Emacs は絶えず普請中ですし、Mule のだめ
;; さは Mule project の member 自身が認めているでしょう（というか、
;; Mule の最大の批判者かも）。特に、language-environment 関連がでたら
;; めなのは project leader も常に問題視しており、font の整備と同時に早
;; 急に何とかしたいテーマの一つとして考えられているようです。

そういう訳で、XEmacs-mule の中途半端な国際化と同様、整合性のある体系と
しての意味はないと思います。


守岡> ;; PGG を user interface を備えない module と捉えるなら 
守岡> ;; coding-systemや locale に関する設定用界面を設けるだけで、
守岡> ;; `set-language-environment' との同期は mime-pgp の責任とする考
守岡> ;; え方もあると思います。でも、PGG には command があるので、個人
守岡> ;; 的には PGGで（も）`set-language-environment' との同期ができた
守岡> ;; 方が良いと思いますが。

Daiki> 基本的に、PGG は SEMI の一部でしかないので、この際、界面を整理
Daiki> して command 群を撤廃するというのも良いのではないかと思います。

それも１つの方向だと思います。

-- 
守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ kanji.zinbun.kyoto-u.ac.jp>