language in SEMI and Mule (Re: binary-start-process)

[守岡 知彦 / MORIOKA Tomohiko]

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

守岡> 現状を前提にとりあえずの解決を行う場合、PGG 専用の
守岡> set-language-environment で設定可能な変数や関数などを設けるのが
守岡> 良いのではないかと思っています。そうすれば、
守岡> set-language-environment で PGGの設定を行うことができます。

Daiki> いや、ですから、何度も言うように、それが僕には判りません。

守岡> 一番簡単なのは pgg-*-coding-system みたいな変数を設けることだと
守岡> 思います。そうすれば、PGG を用いる側が確実に設定を行うことが出来
守岡> ます。

Daiki> いや、ですから、それは僕が最初に守岡さんに提示した解答に過ぎま
Daiki> せん。

はい、その通りです。

Daiki> ;; IRC のログを公開しても良いですか？

;; 必要があるならどうぞ。かなり馬鹿なことを言っていたと思うので、不適
;; 切なことは訂正し、また、必要なら謝罪します。


Daiki> 「set-language-environment で PGG の設定を行うことができ」るのなら、
Daiki> その設定を具体的に見せてください。

判りました。

例えば、PGG に変数 pgg-messages-coding-system と pgg-messages-locale 
があるとして、それが language-info-alist の pgg-messages-coding-system 
属性と pgg-messages-locale 属性で表現されているとすると、

(defun pgg-setup-locale ()
  (setq pgg-message-locale
	(get-language-info current-language-environment
			   'pgg-message-locale)
	pgg-message-coding-system
	(get-language-info current-language-environment
			   'pgg-message-coding-system)))

(add-hook 'set-language-environment-hook 'pgg-setup-locale)

で設定できると思います。

-- 
tomo.

P.S.

守岡> この件に関してはそう思われても仕方がありません。私は悲しいかな、
守岡> 上野さん程野元気や調査力、実装力、時間がありません。

Daiki> 当然、僕も時間はありませんし、悲しいかな、国際化に関する興味も
Daiki> ありません。

はい。それはそれで良いと言って来たつもりです。でも、興味がないからといっ
て undecided で良いだろうと言われるとちょっと悲しい訳です。

;; 少し被害妄想的に言えば、私が関心を寄せる分野について冷淡ないしは尊
;; 重されていない感を受けました。もっとも、これは毎度のことではあるの
;; ですが。そして、他罰的な感を受けました。


Daiki> ;; 面白い問題を面白い枠組として提示して頂けるなら別ですが。

残念ながら、上野さんがどのようなものを面白いと感じるかが判っていません
でした。また、今も多分判っていません。

ただ、いずれにしても私の力が足らなかったのは申し訳ありません。


Daiki> 協同開発において、モデルやコード、ユースケースすらも提示できな
Daiki> い実体は、存在しないも同然ではないかと考えています。

ここでいう実体とは何でしょうか？


Daiki> 岡田さん御自身が Wanderlust という特定の MUA に入れた、SLIM の
Daiki> ためのglue code を、「現在動作しているから変更したくない」とい
Daiki> うのは、あまりにも無責任すぎませんか？

一般論としては同感です。

ただ、その時点の状況によって ad hoc な対処をせざるを得ないこともあると
思います。この場合も、その後の road map を明らかにした方が良いと思いま
すが。

ただ、いずれにしてももう少しものの言いようがあるだろうという感想を持っ
ています。また、モデルやコード、ユースケースをばーんと出せば良いという
もんでもないでしょう。もう少し説明があった方が良いと思います。これらは
つまる所、理解を共有するための言葉の一種だと思うので。もちろん、いずれ
にせよコストはかかるのでするもしないも自由なんだと思いますが。


Daiki> ;; これは、bug report を無視するのと同じレベルだと考えています。

;; これについては本当にすみません。実際にはとりあえず一箇所に溜ってい
;; れば少しずつでも対処していくつもりではあるんですが。近年はちょっと
;; 疲れ気味で特にこの面での意欲が減っていました。


Daiki> コードを書くというのは、文章を書くのと同様に、それなりに責任を
Daiki> 負わねばならないものだと思います。

これはそう思います。

Daiki> その上で、将来的に再利用可能なコードを書くのは、責任の所在をで
Daiki> きるかぎり最小化する試みではないかと。

これはちょっと良く判りません。

それも一つの方法なんだと思いますが。


Daiki> ;; 原作者が一生メンテナンスするというのであれば、話は別ですが。

重要なのは判りやすくすることだと思います。でも、判りやすさというのはそ
う明らかなものではないので、いろんな手法が開発され続けているんだと思い
ますが。


守岡> ただ、更に余計なことを述べれば、上野さんは自分の言動の行間を読む
守岡> ことを他人に求め、また、上野さんの文脈・価値観で他人の言動の行間
守岡> を読んでらっしゃるように思われますが、これは大変危うい態度だと思
守岡> います。みんなが上野さんでない以上、どうしてそんなことが可能なん
守岡> でしょうか？また、上野さんが感じた行間は往々にして誤解になりかね
守岡> ないと思います。書いてないことに勝手に腹をたてるようなことは止め
守岡> た方がうまくコミュニケーション出来るのではないかと思います。

Daiki> 本当に正確に伝えたいと思うのでしたら、そう勘繰られないような形
Daiki> 式的な文章、もしくはコードを書くべきではないでしょうか。

形式的ならばちゃんとコミュニケーションできるとは必ずしも思わないですが、
異質な文化間で最低限のコミュニケーションを行うためには真だと思います。

;; ただ、code を書いてもとりあえずのものを理想的なものと勘違いされたり
;; する恐れがあると思うので、comment や説明文とかもいると思いますが、
;; これを形式化するならば ISO や JIS の規格書のように語彙や概念、形式
;; をまず定義する必要があると思います。もっとも、規格書の努力がむくわ
;; れているかというとあんまりそういう気もしないんですが（往々にして難
;; しくなって理解しづらくなり、誤解されたり、伝えたいことが定義しきれ
;; なかったり、…）。で、そのために解説をつけたりする訳で、現実的にも
;; 形式主義には限界がある気がします。