binary-start-process

[Daiki Ueno]

>>>>> In [emacs-mime-ja : No.00764] 
>>>>>	tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:

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

ううむ。個人的にはまったく逆の立場で、dynamic binding のほうがまだ、
移行は簡単ではないかという感想を抱いているのですが、専用の関数を設けるこ
とで移行の手間が減少する例を挙げて頂けないでしょうか。

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

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

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

何でもできるのでしたら、PGG の場合の、守岡さんの提唱する界面における、
言語環境の設定を見せて頂けませんか？ ;; 不完全なものでも構いません。

こちらは、是非お願いします。

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 の中途半端な国際化と同様、整合性のある体系と
守岡> しての意味はないと思います。

ここで Emacs 21 の例を出したのは、Emacs 21 の実装を基準とするというよりも、
むしろ、XEmacs の auto-language-alist を見ればわかるように、locale name
と言語環境の対応付けが 1:1 ではないために、Emacs 21 はあえて言語環境の変
化に system-messages-locale を追随させなかったのではないかということです。

「Emacs の language environment は基本的に、何かが違ったら言語じゃなくて
も違う『言語』になる」という、守岡さんの言に従うなら、ja_JP.UTF-8 や
ja_JP.eucJP などに対しても、define-language-environment により新たな言語
環境を定義すべきですよね。それも、pgg.el の中でやるべきなのでしょうか。

僕は、界面というものは、あるライブラリについて必ずしも唯一とは限らないと
考えています。例えば、同期/非同期などの特定の semantics、特定の実装法、
粒度、等の様々な面で切ったものこそが界面 (まさにその名前のまま) ではあり、
その場合、界面の一貫性とは単に切断面の選びかたに過ぎないのではないかと。

その意味で、(きっと冗談でしょうが) 守岡さんの仰る binary-funcall などを
用意するというのも一つの方法なのではないかと考えます。例えば Java では、
特定のコンテナに対し同期的なアクセスを保証する(型に変換する)ために、
Collections.synchronizedList (new ArrayList (...)) などという界面を用意
しています。

;; 一応は常に前向きな姿勢ではあります。ただ、中途半端にやるくらいなら、何も
;; しないほうが (つまり Emacs の その時点の auto conversion に任せたほうが)
;; 喜ばれるのは確かなのではないでしょうか。

ともあれ、本気で説得する気があるのでしたら、pgg.el に入れるべき設定を
一部でも良いので、実際に見せてください。
-- 
Daiki Ueno