[chao 1.14] mmexternal anon-ftp

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> <87ya3eb8w8.fsf ＠ sodan.org> にて
>>>>> “Yoshiki”= Yoshiki Hayashi <t90553 ＠ m.ecc.u-tokyo.ac.jp> さま曰く:

Yoshiki> > 確かに関数 expand-file-name が ftp に access したって bug 
Yoshiki> > とは言えないでしょうね。ただ、file-name-handler-alist に指
Yoshiki> > 定された関数は関数 expand-file-name に於いて 
Yoshiki> > expand-file-name の場合の処理を行えと指示された事を知ってい
Yoshiki> > るので、もし、関数 expand-file-name において ftp にaccess 
Yoshiki> > することが望ましくないのであればそう配慮する事が可能でしょ
Yoshiki> > う。一方、ftp に access することが問題なければもちろん問題
Yoshiki> > ありませんが、その場合、Chao-1.14 も現状で良いと言えるでしょ
Yoshiki> > う。

Yoshiki> EFS や ange-ftp の使用を前提として directory 部分に EFS が扱
Yoshiki> う正規表現を書いて expand-file-name を呼べば EFS が ftp で接
Yoshiki> 続するのは問題無いです。ただし、Chao が expand-file-name し
Yoshiki> ているのは intialize-instance の中で、どうみても file 部分と
Yoshiki> directory 部分をくっつけようとしているだけなので、EFS を呼び
Yoshiki> 出すのは無駄です。どういう論理で最後の文に繋がるのかまったく
Yoshiki> わかりません。

file と directory をくっつけるのが expand-file-name の仕事だと期待して
いるわけです。そして、その値は file-name-handler-alist で指定された
application に適合したものが帰ることを期待して expand-file-name を使っ
ているわけです。


Yoshiki> > Yoshiki> 私は bug だと思っていませんが、
Yoshiki> > 
Yoshiki> > よろしければその理由を教えてください。

Yoshiki> XEmacs の Info の Lispref の Node: Magic File Names に

Yoshiki>    Here are the operations that a magic file name handler
Yoshiki> gets to handle:

Yoshiki> [...]
Yoshiki> `dired-compress-file', `dired-uncache', `expand-file-name',
Yoshiki> [...]

Yoshiki> というのがあります。明示的に EFS が使わない用に指示していな
Yoshiki> い限り、ftp で接続に行くのは EFS としては普通の動作だと思い
Yoshiki> ます。

ある file 処理 application において、適切な file 名を作るために原理的
に ftp で接続する必要があれば、その application を使うことを期待してい
る環境ではそうせざるを得ないのではないでしょうか？


Yoshiki> > Yoshiki> ついでに、FSF Emacs 20.7 でも全く同じ挙動をします。
Yoshiki> > 
Yoshiki> > 私の手元の Emacs 20.7 (woody の) では再現できませんでした。
Yoshiki> > なお、EFSは使っていません。

Yoshiki> Package: emacs20-dl
Yoshiki> Version: 20.7-4

Yoshiki> というので
Yoshiki> (expand-file-name "README" "/ftp ＠ ftp.m17n.org:")
Yoshiki> を eval すると
Yoshiki> *ftp ftp ＠ ftp.m17n.org* という buffer ができて、そこで接続し
Yoshiki> ています。もちろん ange-ftp です。

これは再現できました。

多分、

	       (expand-file-name
		name
		(concat "/anonymous@" site ":"
			(file-name-as-directory directory)))

みたいにすべきなんでしょう。


Yoshiki> > それから、これは多分 EFS の問題だと思うので、Emacs 20.7 で 
Yoshiki> > EFS を使えば同様の挙動を示すでしょうし、XEmacs でも EFS を
Yoshiki> > 使わなければそういう挙動を示さないと思われます。

Yoshiki> なぜ EFS の bug なんでしょうか?

分かんないです。


Yoshiki> > ところで、
Yoshiki> > 
Yoshiki> > -		  (name (mime-content-type-parameter ct "name")))
Yoshiki> > +		  (name (mime-content-type-parameter ct "name"))
Yoshiki> > +		  ;; avoid contacting an ftp server.
Yoshiki> > +		  (file-name-handler-alist nil))
Yoshiki> > 
Yoshiki> > という対処ですが、別の理由で反対することにします。それは
Yoshiki> > file-name-handler-alist で特別な file 名の扱いを実現しよう
Yoshiki> > とするapplication が仮にあった時にその機能を阻害するのはま
Yoshiki> > ずいと思われるからです。

Yoshiki> 別の application が裏に存在するなら考慮しなければならないで
Yoshiki> しょうが、mmexternal の下請けの program って何でしょうか? も
Yoshiki> し別の backend を作っていて、この動作が嫌であれば override
Yoshiki> すれば良いだけですよね?

mmexternal の下請けの program とは ange-ftp, EFS 等の 
file-name-handler です。明らかに何らかのこの種の application が存在す
ることを想定していますよね？

また、例えば、ange-ftp や EFS の代わりに別の同種の application を使う
ことにした時に、FLIM でも設定しないといけないとしたら嫌でしょう？

例えば、mjaa-uri という GNU wget を使い URI を spool に cache するよう
な ange-ftp の代替 program を使うとします。この mjaa-uri は邪悪にも
expand-file-name で spool 上の file の場所を返す場合があるとします。そ
うすると、上記の修正は mjaa-uri の動作を阻害することになります。

file 部分と directory 部分を *その application に適合した形で* くっつ
けたいから expand-file-name を使っているのであって、それを阻害するなら
expand-file-name を使うのは理解できません。
-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ m17n.org> ─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━