ファイル名の認識 - 秀丸エディタ関連ソフト会議室 - スレッド07068, 2000/12/22

ファイル名の認識

ひろさん　00/12/22 20:35

　秀丸担当さん今日は、ひろです。
　以前「{}<>」で括られていても、ファイル名として認識して欲しいと要望
を出し、Ver.3.06β で採用されていて、変更履歴にも
> 　　　・ファイル名のカラー表示で'{'と'}'もファイル名区切りとする
とあり「<>」は問題ないのですが、「{}」については私の意図とはちょっと
違います。

　例えば、「{file.txt}」をすると「{}」もファイル名の一部として捕らえ
られてしまいます。つまり「{}」はファイル名の一部として捕らえるのでは
なく、「()<>」と同じように、ファイル名の区切りとして頂きたいのです。
検討頂けないでしょうか?

RE:07068 ファイル名の認識

長澤薫 さん　00/12/25 10:13

こんにちは、長澤です。

>> 　　　・ファイル名のカラー表示で'{'と'}'もファイル名区切りとする
>
>　例えば、「{file.txt}」をすると「{}」もファイル名の一部として捕らえ
>られてしまいます。つまり「{}」はファイル名の一部として捕らえるのでは
>なく、「()<>」と同じように、ファイル名の区切りとして頂きたいのです。
>検討頂けないでしょうか?

でも、<>はリダイレクト記号だからファイル名として使えませんが、
{}は使えますよね？

RE:07072 ファイル名の認識

ひろさん　00/12/25 16:36

　長澤薫さん今日は、ひろです。
> でも、<>はリダイレクト記号だからファイル名として使えませんが、
> {}は使えますよね？
　使える・使えないという話ではありません。それを言うと「() や全角文
字も使える」という話になってしまいます。「{}」については、私が要望を
出したのですが、私の意図とは違っているので、改めて要望を出したのです。
以前は単純に「{}」はファイル名として認識せず、{sample.txt} と書くと
ファイル名として認識せず、{ sample.txt } と書くとファイル名として認
識していました。

　同じ括弧である「()[]」と扱いが違っているので、不自然さを感じるとい
うことと、私が良く使う TeX というマーク・アップ言語で「{}」がファイ
ル名の一部として扱われると、非常に不便なのです。

　ここまで書いていて気付いたのですが、「{}」の両方がファイル名の一部
として認識されるのではなく、「{」だけファイル名として認識されるんで
すね。いっそう変。

RE:07074 ファイル名の認識

長澤薫 さん　00/12/25 17:14

こんにちは、長澤です。

>「{}」については、私が要望を
>出したのですが、私の意図とは違っているので、改めて要望を出したのです。
>以前は単純に「{}」はファイル名として認識せず、{sample.txt} と書くと
>ファイル名として認識せず、{ sample.txt } と書くとファイル名として認
>識していました。
>
>　同じ括弧である「()[]」と扱いが違っているので、不自然さを感じるとい
>うことと、私が良く使う TeX というマーク・アップ言語で「{}」がファイ
>ル名の一部として扱われると、非常に不便なのです。

なるほど！　確かにTeXでは不便かもしれませんし、ほかの括弧との
兼ね合いでも変ですね。そこまで深読みしませんでした。普段はファ
イル名を特別扱いしていないので（C++とかVBとかやっていると、じゃ
まな機能なのよね）……。

RE:07068 ファイル名の認識

秀丸担当 さん　00/12/25 18:12

>とあり「<>」は問題ないのですが、「{}」については私の意図とはちょっと
>違います。

ファイル名終わりの区切りとしてだけ認識して、始めのほうにある{}は
ファイル名の一部として認識してしまっているので変になってしまいま
した。変更しておきます。

RE:07072 ファイル名の認識

秀丸担当 さん　00/12/25 18:12

>でも、<>はリダイレクト記号だからファイル名として使えませんが、
>{}は使えますよね？

空白や日本語などもファイル名として使えますが、これもファイル名
と認識していません。
「ファイル名と思わしき」ですので、どちらのほうが便利かどうか
で判断しています。
{}は区切りにしようと思います。

RE:07074 ファイル名の認識

きいろいまふらあ さん　00/12/25 19:29

（これは）戯言です。

> 　同じ括弧である「()[]」と扱いが違っているので、不自然さを感じるとい
> うことと、私が良く使う TeX というマーク・アップ言語で「{}」がファイ
> ル名の一部として扱われると、非常に不便なのです。

いっそ「ファイルタイプ別の設定」で、

□ファイル名と思わしき場所のカラー表示
　◎一般
　○TeX用

なんてできると便利だったりします？
これだけじゃだめかな？

文章中に埋め込まれた「ファイル名（っぽい文字列）」がカラー表示されても
意味がない、とは言いませんが、これってやっぱりプログラムソース中で
使うことを主眼に置いた機能ですよねぇ？
それを前提として、もうちょっと厳密な評価のロジックは
できないもんですかね？実装するしないは別として。
＃「できるはずだ」って言っているわけじゃないです、念のため。

RE:07078 ファイル名の認識

ひろさん　00/12/26 12:01

　秀丸担当さん今日は、ひろです。
> 「ファイル名と思わしき」ですので、どちらのほうが便利かどうか
> で判断しています。
> {}は区切りにしようと思います。
　有り難うございます。

RE:07082 ファイル名の認識

ひろさん　00/12/26 12:01

　きいろいまふらあさん今日は、ひろです。
> □ファイル名と思わしき場所のカラー表示
> 　◎一般
> 　○TeX用
　これってスペース的に苦しくないかなあ～。また先の発言でも書きました
が、「[]()}」はファイルの区切りで、「{」だけファイル名の一部というの
は違和感を感じます。また便利かもしれませんが、次々に要望が出て収拾が
つかなくなる気がします(^^)。<-要望を書いた本人が言ってるよ。

> 文章中に埋め込まれた「ファイル名（っぽい文字列）」がカラー表示されても
> 意味がない、とは言いませんが、これってやっぱりプログラムソース中で
　むしろ、普通の文書に、メモ代わりで入れておいた場合が一番便利だと思
います。ダブル・クリックなどのマウス操作や、ダイレクトタグジャンプで
関連付けられたアプリケーションでファイルを開けるので重宝しています。

　また C 言語では、却って邪魔になります(^^;。

RE:07088 ファイル名の認識

きいろいまふらあ さん　00/12/26 21:47

ひろさん、どもです。

> > □ファイル名と思わしき場所のカラー表示
> > 　◎一般
> > 　○TeX用
> 　これってスペース的に苦しくないかなあ～。また先の発言でも書きました

「スペース的に」ですか。苦しいですね。
ま、「需要」によるのかもしれません。

> が、「[]()}」はファイルの区切りで、「{」だけファイル名の一部というの
> は違和感を感じます。

すみません、私の書き方が悪かったです。

「ほげほげ.txt」とか「hogehoge(1).txt」とかもファイル名として認識される
モードがあってもよいかなと思いつつ、TeXの場合は（後者は）困るわけだから、
んじゃそれは「TeXモード」にしちゃえばいいのかな？というただの思い付き
に過ぎませんです。

今回の話とは関係ないです。「}」がファイル名の区切りで「{」がファイル名の
一部というのは（深く考えてませんが）直感的に変だなとは思ってました。

> また便利かもしれませんが、次々に要望が出て収拾が
> つかなくなる気がします(^^)。<-要望を書いた本人が言ってるよ。

私もそれは危惧しましたので

> それを前提として、もうちょっと厳密な評価のロジックは
> できないもんですかね？実装するしないは別として。

と「ロジックの有無」の話にしたんです。わかりづらかったですかね？
過去の話も「ロジック」と「実用性」の話がごちゃまぜになってしまって
解決策が見出せなかったような気がしたもので。

いくつかの典型的なパターン（「文章中」「Ｃのソース」「TeXのソース」
などなど）を想定して、それぞれの中で「比較的妥当なファイル名の定義」が
できたら、それはそれでありなんじゃないかな？って思ったのです。
「重くなる」「開発側の負担」「需要」「技術の進歩」などなどとは、
いったん切り離しての話をしてもいいのかな？と。
＃会議室の主旨に合いませんかね？(^^;

> > 文章中に埋め込まれた「ファイル名（っぽい文字列）」がカラー表示されても
> > 意味がない、とは言いませんが、これってやっぱりプログラムソース中で
> 　むしろ、普通の文書に、メモ代わりで入れておいた場合が一番便利だと思
> います。ダブル・クリックなどのマウス操作や、ダイレクトタグジャンプで
> 関連付けられたアプリケーションでファイルを開けるので重宝しています。

はい、私も便利に使っています。でも、そのために全角も()もファイル名の
一部として認識されないならば（それはそれとして）いっそのこと……という
ことを言いたかったのです。通じますでしょうか？

> 　また C 言語では、却って邪魔になります(^^;。

そんなこともあるんだろうなと思ったので

> これだけじゃだめかな？

って書きました。通じてないかな？(^^;

RE:07091 ファイル名の認識

きいろいまふらあ さん　00/12/27 00:17

自分に補足。

>> > □ファイル名と思わしき場所のカラー表示
>> > 　◎一般
>> > 　○TeX用
>> 　これってスペース的に苦しくないかなあ～。また先の発言でも書きました
>
>「スペース的に」ですか。苦しいですね。
>ま、「需要」によるのかもしれません。

仮にスペース的に苦しいこと「だけ」が問題なのだったら
これはもう是非やってもらいたいところです……

……が、現実に、それだけが問題なのではないので、色々難しい
だろうな、とは思ってますよ、私も。

>「ほげほげ.txt」とか「hogehoge(1).txt」とかもファイル名として認識される
>モードがあってもよいかなと思いつつ、TeXの場合は（後者は）困るわけだから、

TeXが困るのは{}でしたね。間違い、間違い。失礼しました。
ま、話の本筋は変わりません。

>> また便利かもしれませんが、次々に要望が出て収拾が
>> つかなくなる気がします(^^)。<-要望を書いた本人が言ってるよ。
>
>私もそれは危惧しましたので
>
>> それを前提として、もうちょっと厳密な評価のロジックは
>> できないもんですかね？実装するしないは別として。
>
>と「ロジックの有無」の話にしたんです。わかりづらかったですかね？

「ロジックの有無」というのもちょっと変な書き方でしたね。
うまい言い換えが思い付きませんが、通じますよね？

>いくつかの典型的なパターン（「文章中」「Ｃのソース」「TeXのソース」
>などなど）を想定して、それぞれの中で「比較的妥当なファイル名の定義」が
>できたら、それはそれでありなんじゃないかな？って思ったのです。

今は、Ｃのソースだろうが、べた書きの文章だろうが、TeXのソース
だろうが、全て同じロジックで「ファイル名と思わしき文字列」を
特定しているけど、使われる場面をもうすこし限定すれば、
それぞれの場面で、今よりも（少しでも）使いやすいロジックが
見つかるんではないか？というようなことです。

もっとも具体的な話をしてしまうと、「べた書きの文章のほとんどの
部分はファイル名とみなすことのできる文字列から構成されている」
なんて話にもなりかねないわけですが、ま、そう短絡的に考えることも
ないか。(^^;

RE:07091 ファイル名の認識

ひろさん　00/12/27 11:38

　きいろいまふらあさん今日は、ひろです。
> と「ロジックの有無」の話にしたんです。わかりづらかったですかね？
> 過去の話も「ロジック」と「実用性」の話がごちゃまぜになってしまって
　「ロジックの有無」の話でしたか、解っていませんでした(^^;。

　まあ厳密には無理でしょう、まずUNIX のドット・ファイルや MAC の拡張
子無しのファイルはこの際無視するとして、「2 バイト・コードが含まれて
いなくて、ユーザが登録した拡張子が付いている文字列を、ファイル名と認
識する」にしたら Windows のみの環境なら比較的使いやすいと思います。

> 「重くなる」「開発側の負担」「需要」「技術の進歩」などなどとは、
> いったん切り離しての話をしてもいいのかな？と。
　上記の発言は、基本的に文字列の最後でファイル名かどうかの判定をする
ことになり、間違いなく「重く」なるでしょう(^^;。また「需要」というの
が重要で、私個人は現状の仕様で、大体満足しています。
> ＃会議室の主旨に合いませんかね？(^^;
　要望の延長ということで、ギリギリ大丈夫ではないかと...。

> はい、私も便利に使っています。でも、そのために全角も()もファイル名の
> 一部として認識されないならば（それはそれとして）いっそのこと……という
> ことを言いたかったのです。通じますでしょうか？
　通じていませんでした(^^;。私はその様な場合、予め範囲選択しておいて
からダイレクト・タグ・ジャンプをしたり、右クリックで「...を開く」
(<-要カスタマイズ) しているので、それで事足りていました。

RE:07093 ファイル名の認識

きいろいまふらあ さん　00/12/27 12:37

ひろさん、こんにちは。
（時間的に）#7092も読んでいただけていると思いつつ。

> 　まあ厳密には無理でしょう、まずUNIX のドット・ファイルや MAC の拡張
> 子無しのファイルはこの際無視するとして、「2 バイト・コードが含まれて
> いなくて、ユーザが登録した拡張子が付いている文字列を、ファイル名と認
> 識する」にしたら Windows のみの環境なら比較的使いやすいと思います。

私個人は、２バイトコードをファイル名に使うことが非常に多いです。
そんなに少数派じゃないと思うんだけどなあ……。
＃MS-DOSの頃は嫌ってましたけどね。かな漢字変換が面倒だから。

> 　上記の発言は、基本的に文字列の最後でファイル名かどうかの判定をする
> ことになり、間違いなく「重く」なるでしょう(^^;。

「文字列の最後でファイル名かどうかの判定をする」ってのがどういう
意味なのか、現状とそんなに違うものなのか私にはわからないんですが、
むしろ「登録した拡張子」なんて限定するほうが面倒そうな…。
＃「上記の発言」て「2 バイト・コードが…」のことですよね？

例えば、某か長さの上限があって（これが難しいかな？）、
　「１文字以上の連続したファイル名に使える文字」
＋「.」
＋「１～４文字の連続するファイル名に使用できる英数字」
をファイル名と思う、なんてのはどうなんでしょうね？

半角スペースの扱いには注意が必要なのかな？全角も？

＃しつこいようですが、机上の話として、です。

RE:07094 ファイル名の認識

ENCODINGSHIFTJIS さん　00/12/27 17:26

途中で割り込みますが
hateマークアップ派ならではの議論にきこえます。
表示だけなら、「思わしきところ」で少々のズレは影響ないが
処理に使用するためには「思っているとおり」正確じゃないとダメ。
ここですね、では表示は現行のままで「...を開く」などの実行直前に
colorcode をヒントにして範囲較正するマクロを当てたらどうでしょう、
文体ごとに最適化できるし。慣用法が定着してから秀丸に組み込んでも
よいのでは?

RE:07094 ファイル名の認識

ひろさん　00/12/27 19:43

　きいろいまふらあさん今日は、ひろです。
> （時間的に）#7092も読んでいただけていると思いつつ。
　読んでます。ただ引用の関係で、7091 の方がレスが付けやすかった(^^)。

> 私個人は、２バイトコードをファイル名に使うことが非常に多いです。
> そんなに少数派じゃないと思うんだけどなあ……。
　確かに少数派ではないと思います。
　ただ2 バイト・コードも含めてしまうと、あまりにも処理が遅くなるし、
あまりに多くの文字列がファイル名として認識されてしまい、編集画面が見
にくくなると思います。というのは、理工系の文章では「、。」の代わり
に「,.」を使っていることが多々あるからです。

> むしろ「登録した拡張子」なんて限定するほうが面倒そうな…。
　確かに面倒ですが、これが無いと現在の仕様とあまり変わらないので、
C 言語の構造体が全滅です(^^)。->ですから今は OFF にしています。

> 例えば、某か長さの上限があって（これが難しいかな？）、
　Windows では「.」と拡張子を含めて 256 文字でしたっけ???

> ＃しつこいようですが、机上の話として、です。
もちろん机上の話としてですが(^^;、それでも 2 バイト・コードと空白は
除外した方が、返って見易いような気がします。例えば、
「一緒にお送りしたsample.txtを参照してください。」と書く場合、きいろ
まふらさんの仰る仕様では、sample.txt もファイル名として認識せず、使
い勝手が落ちてしまいます。

RE:07101 ファイル名の認識

えるさん　00/12/27 20:01

ボソっと技術的なフォロウだけ

>　Windows では「.」と拡張子を含めて 256 文字でしたっけ???

Win95/98 ではファイル名全体で 260 バイトまで。
WinMe/NT3.51/NT4/200 では制限なし。

RE:07101 ファイル名の認識

きいろいまふらあ さん　00/12/27 21:18

推敲する癖がつくのはいいことだなあ……。＞自分

> 　ただ2 バイト・コードも含めてしまうと、あまりにも処理が遅くなるし、

そーいうものなんですか？

> あまりに多くの文字列がファイル名として認識されてしまい、編集画面が見
> にくくなると思います。というのは、理工系の文章では「、。」の代わり
> に「,.」を使っていることが多々あるからです。

同感です。その辺はやはり気になるので……

> > 例えば、某か長さの上限があって（これが難しいかな？）、

……と書いたのです。＜やっぱりわかりにくいね(^^;
だからこの「長さ」云々は……

> 　Windows では「.」と拡張子を含めて 256 文字でしたっけ???

……これに合わせようって話じゃなくて、
あんまり長いのはファイル名とみなさないようにしたらどうかな？
ってことなんです。
「難しいかな？」＝「妥当な上限を決めるのは難しいかな？」です。

> > むしろ「登録した拡張子」なんて限定するほうが面倒そうな…。
> 　確かに面倒ですが、これが無いと現在の仕様とあまり変わらないので、
> C 言語の構造体が全滅です(^^)。->ですから今は OFF にしています。

「登録した拡張子」は、ひきあいに出しただけで、「そんな面倒な処理は
させないほうがいい」とか言っているわけじゃないです。

私は場面場面でルールを使い分けることを前提に話をしています。
＃自分で言っておきながら、場面を特定せずに話をしてしまい、
＃混乱させてしまってますね。すみません。

２バイトやら括弧やらをファイル名として認めるようなルールは、
そうなってもあまり支障のない場面でのもの、として考えています。
例えばべた書きの文章中とかね。

Ｃのソース（ですよね？）の中では、そこに見合った基準があればよい、と。
で、少なくともそこでは「登録した拡張子」を意識したルールが妥当
なのでしょう、ひろさんの書かれた文章を読む限り。
＃私、Ｃは（も）未経験者に限りなく近いので……。(^^;

> 「一緒にお送りしたsample.txtを参照してください。」と書く場合、きいろ
> まふらさんの仰る仕様では、sample.txt もファイル名として認識せず、使
> い勝手が落ちてしまいます。

まさにその通りです。
で、「一緒にお送りした sample.txt を参照してください。」と書けば
認識してくれるようなルールも考えられると思うのですが、
いかが思われますか？ファイル名として認識させるために空白を
入れなきゃならないなんて本末転倒！ですか？

でも、自分で書いて自分で読むケースがほとんどだと思うしなあ……。
＃相手が秀丸で読むことが期待されるのは、例えば秀丸マクロの
＃ドキュメントとかその類に限定されるでしょ？(^^;

私がもうちょっと具体的な例を出せばいいのでしょうね。
＃でも、そこまでアイディアは固まってないのだな。(^^;

RE:07096 ファイル名の認識

きいろいまふらあ さん　00/12/27 21:18

ENCODINGSHIFTJISさんこんにちは。いや、こんばんは。
変な意味じゃないんですけど、文章が（私にとっては）洗練され過ぎていて
ちょっと意味を取り違えてしまってるかもしれませんがご容赦。

> 表示だけなら、「思わしきところ」で少々のズレは影響ないが
> 処理に使用するためには「思っているとおり」正確じゃないとダメ。

ですね。ま、なんにしても後者の完全な実装っていうのは、直感的に
不可能なのかな？と思っていて、じゃ、それぞれの場面（文体）を別々に
考えたら、それぞれの文体の中でもう一歩か二歩くらいは「完全」に
近づけるかなあ？というところです。くどくてすみません。

> ここですね、では表示は現行のままで「...を開く」などの実行直前に
> colorcode をヒントにして範囲較正するマクロを当てたらどうでしょう、

正規表現で強調表示する、ってことですか？
あるいは、それも含めて好きにしなさい、ってことかな？

> 文体ごとに最適化できるし。慣用法が定着してから秀丸に組み込んでも
> よいのでは?

まったく仰る通りです。色々試してみる気になりました。
的確なご指摘痛み入ります。感謝。

RE:07106 ファイル名の認識

ENCODINGSHIFTJIS さん　00/12/28 11:59

マイ・ファイル名パターン対応のを作ってみました。
外部から来る不特定多数のファイル名を対応しなくてよいなら
個人の範囲では変なファイル名でもパターンは
見つけられると思う。

// myOpenbyHide.mac ローカルルールのファイル名対応
// 正規表現は大文字小文字を区別する
// ファイル名範囲の補正をしてから「秀丸で開く」
// 右クリックメニューになら入る
//
searchdown "\\.[0-9A-Za-z~]+[ 　]",regular;// 末尾パターンは範囲が狭い
searchdown "[ 　]",regular;
beginsel;
searchup "[ <][CD]:|[]\\\\|[ ]/",regular; // 先頭は難しい
right;
openbyhidemaru;

// C:\Windows\ﾃﾞｽｸﾄｯﾌﾟ\djdj.peg C:\Windows\djdj.peg
// サーバーのプログラムじゃないからエラー処理なし

RE:07103 ファイル名の認識

ひろさん　00/12/28 12:10

　えるさん今日は、ひろです。
> Win95/98 ではファイル名全体で 260 バイトまで。
> WinMe/NT3.51/NT4/200 では制限なし。
　情報有り難うございます。
　##WinMe/NT3.51/NT4/2000 は制限無しなのかあ～。

RE:07105 ファイル名の認識

ひろさん　00/12/28 12:10

　きいろいまふらあさん今日は、ひろです。
> > 　ただ2 バイト・コードも含めてしまうと、あまりにも処理が遅くなるし、
>
> そーいうものなんですか？
　これはプログラム的にというわけではなく、「ファイルとして認識すべき
文字が増えると、その文処理が遅くなるだろうなあ～」ということです。

> > > 例えば、某か長さの上限があって（これが難しいかな？）、
>
> ……と書いたのです。＜やっぱりわかりにくいね(^^;
> だからこの「長さ」云々は……
>
> > 　Windows では「.」と拡張子を含めて 256 文字でしたっけ???
>
> ……これに合わせようって話じゃなくて、
　却って解ににくくしてしまったようです(^^;。「どうせ文字数に上限を付
けるなら、Windows で許される文字数にすればよいか」程度のことなので、
あまり気になさらないでください。

> 私は場面場面でルールを使い分けることを前提に話をしています。
　その前提が解っていませんでした(^^;。
　ただどういった規則をデフォルトにするかという問題は残りますが、場面
場面で使い分けるなら、プログラムにその機能を持たせるず、「認識されな
い場合は、選択して～」で良いと思います。
　##どうせ厳密な判定は、人じゃないと出来無さそうだし。

> Ｃのソース（ですよね？）の中では、そこに見合った基準があればよい、と。
　私は元々場面場面でルールを使い分けることを前提にしていません。もし
仕様を変えるとしたら、「～というロジックを加えると、C のソース・ファ
イルでもこの機能が有効になるのではないか?」という意味です。

> いかが思われますか？ファイル名として認識させるために空白を
> 入れなきゃならないなんて本末転倒！ですか？
　理由は後で書きますが、本末転倒でしょう(^^)。
> でも、自分で書いて自分で読むケースがほとんどだと思うしなあ……。
> ＃相手が秀丸で読むことが期待されるのは、例えば秀丸マクロの
> ＃ドキュメントとかその類に限定されるでしょ？(^^;
　私は秀丸のドキュメント、というか秀丸ユーザには限定してません。同じ
ロジックを用いている鶴亀のユーザも想定しています。後者の場合、ダイレ
クト・タグ・ジャンプは関係ありませんが、メールの本文でファイル名を別
色で表示しているユーザもあると思っています。