binary-start-process

[Daiki Ueno]

とりあえず、本題に関しては、

(1) pgg-messages-coding-system は defvar でこっそり定義する。

(2) mime-mailcap-method-messages-coding-system を導入。

という 2 点で合意したつもりです。

;; (2) は、汚いものを入れたことを守岡さんに忘れないで頂けるよう、願いを込めて。

;; 以下、情報量はありませんので、無視してください。

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

守岡> ;; むしろ、私が密かに願っていたのは、pgg で使用するより良い言語
守岡> ;; 環境に関する枠組を汎用的な形で上野さんが作ってくれることだっ
守岡> ;; たんですが、これはないものねだりと言わざるを得ないでしょう。

Daiki> 最初からそう言うべきでしょう。

守岡> そうですね。でも、多分、私自身が良く判ってなかったのでしょう。無論、こ
守岡> れは救いがたい私の問題です。

Daiki> 巧妙に犯人を PGG に押しつけることで、僕に仕事を回そうとしたその
Daiki> 態度に、とても腹を立てています。

守岡> だから、何度も言っているように私は誰かや誰かを糾弾するつもりはありませ
守岡> ん。これは作品に関しても同様です。それとも PGG は上野さんの縄張で、そ
守岡> れを荒すと腹が立つんでしょうか？

無論、header に GPL と明記してある以上「荒らす」のは自由です。

しかしながら、今回のような API の変更を伴う荒らしかたには抵抗があります。

たとえ小さなものであれ、それが守岡さんや岡田さんのような大きな影響力を
もつ方々の手によるものである以上、sasl.el の API のように、将来的に深刻な
問題となる可能性もあるでしょう。

また、個人的には、(受け売りですが) シンプルさというのはかなり重大な要素
だと考えています。

;; 99% の柔軟性を保証する大規模なフレームワークと、90% の柔軟性のうえで
;; code size を小さくしたものと、どちらがより将来性があるかと問われれば、
;; 答えは自明ではないでしょう。

;; また、セキュリティなどの様々な外部要因からなる制約を考慮した場合に、
;; プログラマは自ずと記述可能性を制限するのではないでしょうか。
;; 界面をいたずらに肥大化させておくのは得策とは思えません。

将来的に language environment next generation のような新しい枠組が完成し
た暁には、PGG の実装に pgg-*-coding-system を利用するかも知れません。

しかしながら、gettext により表示の振舞いが直交化された外部プログラムの呼
出しという横木に対し、coding-priority-list や modify-coding-system-alist
を駆使するよりもスマートな設定法があみだされているかも知れません。

というわけで、今は入れたくはありませんでした。

守岡> ただ、確かに私は、誰かがやってくれるとうれしいので、上野さん以外にも、
守岡> やれそうな人だと思うとつい甘えたことを言ってしまうことが多いと思います。
守岡> で、これはたかりの一種で御不快に思われることは理解できます（でも、ここ
守岡> まで激烈な反応を返されたのは驚きですが）。この件に関しても謝罪します。

きっと甘えかたに問題があったのではないでしょうか。

;; 気まぐれプログラマなので、人に騙されて実装することほど嫌なことはありません。
-- 
Daiki Ueno