要望No.07758
bouz さん 05/05/16 09:23
 
毎度ネタ的ではありますが。

* カーソルの加速とちょうど逆のイメージで、減速というもの。
Firefox で PageDown/Up すると最後・最初に達するとブレーキがかかるような感じ
でスクロールする。なかなか気持ちがいい。
同じような機能が秀丸にも欲しい。

* ./hoge.c や ../hoge.c hoge/hoge.c はファイル名になるが、
hoge.c/hoge.cpp だとならない。

[ ]
RE:07758 要望No.07766
秀丸担当 さん 05/05/16 18:00
 

>* カーソルの加速とちょうど逆のイメージで、減速というもの。
>Firefox で PageDown/Up すると最後・最初に達するとブレーキがかかるような感じ
>でスクロールする。なかなか気持ちがいい。
>同じような機能が秀丸にも欲しい。

見て見ましたが、カーソル移動の減速というより、スムーススクロールが有効な
ときにキーリピート中はスムースせず、最後の1ページだけスムースになってい
るためそう見えるようです。
秀丸にもなめらかスクロールの機能はありますが、FireFoxのようにはなりませ
ん。
ネタとして参考にしたいと思います。

>* ./hoge.c や ../hoge.c hoge/hoge.c はファイル名になるが、
>hoge.c/hoge.cpp だとならない。

これは、ファイル名と思わしきところなので、厳密にファイル名として有効かど
うかは判断していません。
一般的に拡張子付きのフォルダというのはあまり無いので、ファイル名と思わし
くないと決めてしまっただけです。

[ ]
RE:07766 Re:^要望No.07767
クラフト さん 05/05/16 18:28
 
お世話になっております。

>>* ./hoge.c や ../hoge.c hoge/hoge.c はファイル名になるが、
>>hoge.c/hoge.cpp だとならない。
>
>これは、ファイル名と思わしきところなので、厳密にファイル名として有効かど
>うかは判断していません。
>一般的に拡張子付きのフォルダというのはあまり無いので、ファイル名と思わし
>くないと決めてしまっただけです。

蛇足です。
Javaのパッケージフォルダなどはほぼ確実に"."がついていたりするので、「アプリ
ケーション開発者」の観点からすると一般的になってきているかもしれません。

[ ]
RE:07767 Re:^要望No.07769
shino さん 05/05/16 20:08
 
>Javaのパッケージフォルダなどはほぼ確実に"."がついていたりするので、「アプリ
>ケーション開発者」の観点からすると一般的になってきているかもしれません。

Javaの場合、パッケージ名に"."が入っていても、実際は"."を"\"に置き換えた階層
になります。
たとえば、

package A.B;
class Test{
}

は、
A.B.Testというクラス名になりますが、ファイルはA\B\Test.class(もしくはA/B/Tes
t.class)となります。

[ ]
RE:07769 Re:^要望No.07771
クラフト さん 05/05/16 23:06
 
>>Javaのパッケージフォルダなどはほぼ確実に"."がついていたりするので、「アプ
>リケーション開発者」の観点からすると一般的になってきているかもしれません。
>
>Javaの場合、パッケージ名に"."が入っていても、実際は"."を"\"に置き換えた階層
>になります。
>たとえば、
>
>package A.B;
>class Test{
>}
>
>は、
>A.B.Testというクラス名になりますが、ファイルはA\B\Test.class(もしくはA/B/Te
>st.class)となります。

私の仕事してるところだけ特殊なのかもしれませんね。
情報ありがとうございました。

[ ]
RE:07766 要望No.07775
bouz さん 05/05/17 00:05
 
>見て見ましたが、カーソル移動の減速というより、スムーススクロールが有効な
>ときにキーリピート中はスムースせず、最後の1ページだけスムースになってい
>るためそう見えるようです。
あ、そうだったんですか。たしかに general.smoothScroll が true になっていまし
た。
アパーチャサイズを増やして描画が快速になったとき勢いで true にしたのを忘れて
いました。

>秀丸にもなめらかスクロールの機能はありますが、FireFoxのようにはなりませ
>ん。
>ネタとして参考にしたいと思います。
よろしくです。

>これは、ファイル名と思わしきところなので、厳密にファイル名として有効かど
>うかは判断していません。
>一般的に拡張子付きのフォルダというのはあまり無いので、ファイル名と思わし
>くないと決めてしまっただけです。

ええと、決めてしまっただけなら、単純に生かしてもらえませんか?
拡張子付きディレクトリが、なんで俺だけのけものなんだ、って言ってます。

[ ]
RE:07775 要望No.07778
秀丸担当 さん 05/05/17 10:34
 

>ええと、決めてしまっただけなら、単純に生かしてもらえませんか?
>拡張子付きディレクトリが、なんで俺だけのけものなんだ、って言ってます。

単純に生かすといっても、hoge.c/hoge.cpp の hoge.c はフォルダ名なのでしょ
うか? たぶんファイル名が2つなのだと思います。
一方、クラフトさんのおっしゃるように、.を含んでもフォルダ名が一般的な使
い方もあるようです。
ファイルの存在を常にチェックしない限り、秀丸は単純に判断できません。

[ ]
RE:07778 要望No.07785
bouz さん 05/05/17 13:48
 
>単純に生かすといっても、hoge.c/hoge.cpp の hoge.c はフォルダ名なのでしょ
>うか? たぶんファイル名が2つなのだと思います。
フォルダ名ですよぉ。もちろん。(-_-)
ファイル名なら空白入れてつながらないようにしときます。

>一方、クラフトさんのおっしゃるように、.を含んでもフォルダ名が一般的な使
>い方もあるようです。
>ファイルの存在を常にチェックしない限り、秀丸は単純に判断できません。

??存在チェックせずに、単純にはじいてるだけだ、おっしゃっていたので、単純に、
単純にはじくのやめてください、と言ってるだけなのですが。なにか無理があります
か?

[ ]
RE:07785 要望No.07789
アルビレオ さん 05/05/17 16:35
 
秀丸ユーザーのアルビレオです。

>??存在チェックせずに、単純にはじいてるだけだ、おっしゃっていたので、単純
>に、
>単純にはじくのやめてください、と言ってるだけなのですが。なにか無理があります
>か?

このような話は過去にも何度か出ているのですが、パスとして使える文字列を可
能な限り認識するようにすると非常に多くの文字列がファイル名扱いになり使い
物にならないので「比較的よくあるパターン」だけを認識するという形で今に至
っています。
拡張子付きディレクトリ名を認識しないで困るのと、普通にピリオドが含まれた
文字列をパス名と誤認して困るのとどっちが多いかという話になりますね。

bouzさんの場合ではどういう形のテキストになっているのかわかりませんが、
「タグジャンプ」だとけっこう高確率でパスを認識してくれます。
#07758で言及している「ファイル名」というのはあくまで強調表示のときの「フ
ァイル名と思わしき場所」であって、タグジャンプ機能には影響しません。

私としては「拡張子付きのディレクトリ名なんて空白入りのディレクトリ名より
もずっと一般的でないよなあ、たまに出てきてもたいていはタグジャンプで事足
りるし」と思っちゃったりします。
というわけで賛成も反対もしません。

[ ]
RE:07789 要望No.07793
bouz さん 05/05/17 17:47
 
こんにちは。
このレスでは多少長く説明しなければならないようです。

>このような話は過去にも何度か出ているのですが、パスとして使える文字列を可
>能な限り認識するようにすると非常に多くの文字列がファイル名扱いになり使い
>物にならないので「比較的よくあるパターン」だけを認識するという形で今に至
>っています。

でしょうね。大体察しが察しが付きます。ないほうがおかしい。
しかし、.の後ろに文字があって使い物にならなくなるというのはどういった文章の
ことでしょうか?
おそらく、何かの整形コマンドの類か何かであるはずで、自分でふだん使う文章には、
ないです。
ボクの使い方としては、ファイル名を書く場合、タグジャンプできる形式で保存して
おくことはtagsをのぞいてありません。
例えば
// hoge.c (4)
などコメントの中に書いたり、メモとして使うテキストの中に、インラインタグ的に
入っています。しかし、こうしておくと標準のタグジャンプは使えません。となると
自分なりにタグジャンプを拡張させる必要があります。その中の目安として、ファイ
ル名と思わしき部分、は重要な要素です。なぜなら、これが旨く働いてくれないと、
ファイル名解析を1から行わなくてはなりません。
いまのところ、これが旨く動作しないのは、拡張子付きディレクトリのほかに、Cygw
in を使っているので、.で始まるファイルがはじかれます。前者は、たとえば hoge
1.1 とか hoge1.2(ごく普通に使います。) や .ssh .w3m というようなもの、後者
は、.bashrc とか .emacs とかそういったものです。だったら、emacs 使えよ、って
話なんですが、そうも行かないのです。やはり秀丸のほうが軽快だし、使い心地がい
い。長年使っているしいいとこ取りしたい。だから、

>拡張子付きディレクトリ名を認識しないで困るのと、普通にピリオドが含まれた
>文字列をパス名と誤認して困るのとどっちが多いかという話になりますね。
>

ボクの場合は100%認識しないで困るほうなんです。

>bouzさんの場合ではどういう形のテキストになっているのかわかりませんが、
>「タグジャンプ」だとけっこう高確率でパスを認識してくれます。
>#07758で言及している「ファイル名」というのはあくまで強調表示のときの「フ
>ァイル名と思わしき場所」であって、タグジャンプ機能には影響しません。

百も承知です。ファイル名〜は強調表示の一種と考えています。
だから、.に続く文字を含む一連の文字列を自前で強調表示する、という手もありま
す。しかし、これだとファイルタイプごとに常にどの強調を使うのか揃えておかなけ
ればならないので、管理が面倒です。ここはあまりいじりたくない。
というわけでビルトイン強調としてのファイル名〜がとても重要なのです。

>
>私としては「拡張子付きのディレクトリ名なんて空白入りのディレクトリ名より
>もずっと一般的でないよなあ、たまに出てきてもたいていはタグジャンプで事足
>りるし」と思っちゃったりします。
>というわけで賛成も反対もしません。

環境は人それぞれなんで、一概に決められませんが、少なくとも
認識できてそれをオフれる選択肢に比べて、認識すらしない、というのはかなりな冷
遇だと思います。

ファイル名とはいっても、フルパスで書かないかぎり、カレントディレクトリが動け
ば一切使えないので、開けるかどうか、というのは無意味です。こうした矛盾を少し
でも解決するために、環境変数を展開してはどうかな?と投げかけましたが、散々な
目に遭いました。(^_^;)

繰り返しますが、拡張子付きディレクトリ、というよりも、.の後ろに文字があった
ら、まずはファイル名として認識しようとして欲しい、
ということです。内部的にははじいているだけらしいので、ボクとしてはオプション
でオン/オフ出来るのがいいんですけど。
スライダでもいいかもしれません。
ファイル名認識度を下げる/上げる、みたいな。

[ ]
RE:07785 要望No.07794
秀丸担当 さん 05/05/17 17:49
 

>フォルダ名ですよぉ。もちろん。(-_-)
>ファイル名なら空白入れてつながらないようにしときます。

フォルダ名でしたか。失礼しました。
ですが一般的にはファイル名と思わしくないと思いますので、はじくのが適切な
のではないかと思います。
意見として参考にしたいと思います。

[ ]
RE:07793 要望No.07797
アルビレオ さん 05/05/17 18:26
 
アルビレオです。

>ボクの使い方としては、ファイル名を書く場合、タグジャンプできる形式で保存して
>おくことはtagsをのぞいてありません。
>例えば
>// hoge.c (4)
>などコメントの中に書いたり、メモとして使うテキストの中に、インラインタグ的に
>入っています。しかし、こうしておくと標準のタグジャンプは使えません。となると
>自分なりにタグジャンプを拡張させる必要があります。その中の目安として、ファイ
>ル名と思わしき部分、は重要な要素です。なぜなら、これが旨く働いてくれないと、
>ファイル名解析を1から行わなくてはなりません。

ちょっと誤解があるようですが、タグジャンプで認識可能な形式というのはかな
り許容範囲が広いです。

// hoge.c

はちょっと無理ですが

/*
    hoge.c
    hoge.c/hoge.h
    ../hogehoge.txt
*/

ならタグジャンプ可能です。

#include "hoge.h"

もタグジャンプで開けます。

ダメなパターンもあるかもしれませんが、いろいろ試してみてはどうでしょうか。

あと、コメントにファイル名を埋め込むと標準のタグジャンプは使えない、とい
うのがよくわからないのですが…
tagsということはダイレクトタグジャンプのことだと思いますが、使えなくなる
理由は思い当たりませんでした。

[ ]
RE:07797 要望No.07799
bouz さん 05/05/17 18:36
 
>ちょっと誤解があるようですが、タグジャンプで認識可能な形式というのはかな
>り許容範囲が広いです。
>
>// hoge.c
>
>はちょっと無理ですが
>
>/*
>    hoge.c
>    hoge.c/hoge.h
>    ../hogehoge.txt
>*/
>
>ならタグジャンプ可能です。
>
>#include "hoge.h"
>
>もタグジャンプで開けます。

なぜか無理なやつを一番使うんですよ〜。

>あと、コメントにファイル名を埋め込むと標準のタグジャンプは使えない、とい
>うのがよくわからないのですが…
>tagsということはダイレクトタグジャンプのことだと思いますが、使えなくなる
>理由は思い当たりませんでした。

通じてないです。(;_;)
// hoge.h
; hoge.h
にタグジャンプできませんが、これがもっともよく使うパターンなんです。何て天の
邪鬼。。。

早々に秀丸担当さんに却下されちゃったし、やはり独自の道を歩むしかなさそうです
ね。(^_^;)

[ ]
RE:07799 要望No.07801
bouz さん 05/05/17 18:45
 
>にタグジャンプできませんが、

「に」、じゃないです。「から」

すいません。出かけなきゃいけないとこで大急ぎで
意味不明なこと書いてしましました。
とにかく標準で出来ない場合でばっかりなぜか使いたがる傾向がある。
ということでおわかりいただけたでしょうか?

[ ]
RE:07799 要望No.07802
アルビレオ さん 05/05/17 19:08
 
アルビレオです。

>通じてないです。(;_;)

ああっ!
tagsファイルからのタグジャンプができなくなると受け取ってました(汗)

>// hoge.h
>; hoge.h
>にタグジャンプできませんが、これがもっともよく使うパターンなんです。何て天の
>邪鬼。。。

いや、秀丸が対応しきれていないというだけで書き方としてはそんなに珍しいも
のではないと思いますよ。


せっかくなので、もうひとつ手段を考えてみます。

// file:hoge.c/hoge.h

これならいけました(笑
ただし、普通にダブルorトリプルクリックするとシェルで関連付けられたアプリ
で開こうとするので秀丸で開かれるとは限りません。
「選択して右クリック」メニューに「...を秀丸で開く」を追加するといいかも。

[ ]
RE:07799 要望No.07803
Iranoan さん 05/05/17 19:09
 
 bouz さん今日は、Iranoan です。
> ; hoge.h
> にタグジャンプできませんが、これがもっともよく使うパターンなんです。何て天の
> 邪鬼。。。
 要はファイル名として扱われないことではなく、ジャンプできないことが問
題なのですよね。それならマクロを作ってしまった方が早そうです。例えば、
例外処理がなければ、末尾の様なマクロです。
 ##私も個人的にはディレクトリ名に「.」があっても良い気がしますが...。
//--------------------------------------------------------------------
disabledraw;
#x = x;
#y = y;
while( ( code <= 'Z' && code >= 'A' ) ||
       ( code <= 'z' && code >= 'a' ) ||
       code == '\\' || code == '/' || code == '.' || code == '_' code == ':'
)left;
if( !column )right;
beginsel;
moveto #x, #y;
while( ( code <= 'Z' && code >= 'A' ) ||
       ( code <= 'z' && code >= 'a' ) ||
       code == '\\' || code == '/' || code == '.' || code == '_' code == ':'
)right;
openbyhidemaru;
endsel;

[ ]
RE:07802 要望No.07805
bouz さん 05/05/18 09:16
 
おはようございます。
>ああっ!
>tagsファイルからのタグジャンプができなくなると受け取ってました(汗)
(^^)

>せっかくなので、もうひとつ手段を考えてみます。
>
>// file:hoge.c/hoge.h

いいですね〜。これが一番自分のマクロに適しています。
これなら、空白も置き換えておいて、跳ばすとき置換すればいいので万全! ボクが求
めていたのは、こういうことなんです。
いちいち file: と書くのがあれですが、とにかく認識しないものはこれ入れといて、
見るべき colorcode をファイルタイプの他に url か?それもみて、 file: があっ
たら同じように処理すればいいだけです。
いやぁ、本当にありがとうございました。

[ ]
RE:07803 要望No.07806
bouz さん 05/05/18 09:35
 
おはようございます。
> 要はファイル名として扱われないことではなく、ジャンプできないことが問
>題なのですよね。それならマクロを作ってしまった方が早そうです。例えば、
そうじゃないって。。。(^_^;)

>例外処理がなければ、末尾の様なマクロです。
だから、そういう風なことをしたくないので、ファイル名〜の認識度を上げてくれ、
って要望なんですよぉ。
なぜしたくないかといえば、大半は秀丸の内部コードで処理されているからです。
弁当の使い捨て容器ももったいない、こんなことでいいのか、と常日頃から考えてし
まうようなリサイクル男なので、
いっぺんやってあるものをまたやるというのがどうにもこうにも嫌いなんです。やり
たくない。美しくない。

> ##私も個人的にはディレクトリ名に「.」があっても良い気がしますが...。
そうでしょ?ですよね〜。なぜ執拗に抵抗されるか解らない。
小泉首相が靖国参拝のことをとやかく言われるのが解らない、というのと同じくらい
解らない。
ファイルの存在確認など金輪際しなくて良いので、大した被害もないと思うんですが。
ためしに、正規表現で自分で使うようなファイル名に合致するように
強調表現を追加してみましたが、ファイル名が圧倒的に増えました。
もちろん、本来ファイルとして記述したのでないもの、たとえば
1.2/1.3
とかいう文字も強調されてしまいましたが、別にどうってことない。
そこからジャンプしようなんて考えないですから。
むしろ注意をひいて表現上いいくらいです。
がやはり正規表現だけでは回りくどくて無理がある。だから。。。
朝からぐちぐちゆうてしもうた。

[ ]
RE:07793 要望No.07813
M.D.S.-Toy さん 05/05/18 11:50
 
Toyです。

昨日から書きこむか否か散々迷っていたのですが・・・。


まず、個人的には"."がフォルダ名から除外されるのは確かにどうなのかなと思って
います。"."入りのフォルダ名がそんなにイレギュラーなものだとも思いませんし。
ただ、たとえば "hoge.c/hoge.cpp" が「ファイル hoge.c と hoge.cpp」なのか「ho
ge.c ディレクトリのファイル hoge.cpp」なのかは秀丸からは判断のしようがないわ
けです。
誤判断を減らすために「思わしき場所」の範囲を狭めるという選択もそれはそれで妥
当なものなのだと思います。
ではそこを判断できるようにオプションを付けてくれ、という主張は理解できますが

>自分でふだん使う文章には
>ボクの使い方としては
>ボクの場合は

ご自身で、自らの使用法がイレギュラーであることは認めておられるようですから、
そこは自己責任かという気がします。
ご自身で解決するスキルは十分お持ちのようですし。
私は、あまり本体が肥大化されることは好まないです。個々人の主張をいちいち取り
入れられて肥っていくのはちょっとどうかと思います。
副作用が間違いなくあるであろう機能追加であればなおさらです。
(無論ソフトウェアに対する思想の違いと言ったらそれまでですが。)


もちろん最終的には秀丸担当さんがメリットデメリットを勘案して採用不採用を決め
られるわけなので、それに従う(もしくは離れる)わけなんですが。

# いや、ちょっとやそっとでは離れないですが。(笑


と前置きをした上で。

>しかし、.の後ろに文字があって使い物にならなくなるというのはどういった文章の
>ことでしょうか?

java のソースコードでは、「ファイル名と思わしき場所」はまったく使い物になり
ません。
ON にすると、画面のほとんどが「ファイル名と思わしき場所」に該当すしますから。
on_
まあこれは現行仕様でもbouzさんが言われる仕様にしても同じなんですがね。

>繰り返しますが、拡張子付きディレクトリ、というよりも、.の後ろに文字があった
>ら、まずはファイル名として認識しようとして欲しい、
>ということです。

bouzさん自身が言われていましたが、"."から始まるファイル名もありますし、また、
拡張子がないファイルだってあります。"1234.567" という文字列はファイル名でし
ょうか数値でしょうか?
そんなわけで、"." の後ろに文字があるかどうかという問題でもないかと思います。

[ ]
RE:07806 ファイル名の認識No.07814
Iranoan さん 05/05/18 12:47
 
 bouz さん今日は、Iranoan です。
> だから、そういう風なことをしたくないので、ファイル名〜の認識度を上げてくれ、
> って要望なんですよぉ。
 そうはいっても、単純にあげると誤認識も増えるので。
 あと http://www.maruo.co.jp/turukame/3/x07758_.html#7813
> java のソースコードでは、「ファイル名と思わしき場所」はまったく使い物になり
> ません。
を読んで思い出したのですが、JAVA だと確かにクラスのことを考えると、
「ファイル名と思わしき場所」で処理しようとすること自体無理か有る気がし
ます。

 結局は、
> 正規表現で自分で使うようなファイル名に合致するように
> 強調表現を追加してみましたが、ファイル名が圧倒的に増えました。
と同様のことを減らすために、現在の仕様になっている、というだけの事だと
思います。

> やはり正規表現だけでは回りくどくて無理がある。
 私がやるとしたら、
[A-Za-z:./\\_]+\.[A-Za-z][A-Za-z0-9]{0,3}
かな。

 私は「.」の扱いより寧ろ、「,」の扱いが解りません。
a.txt, b.txt をコピー
という文章はよくあると思うのですが、「,」があるとその前の部分もファイ
ル名とならない、というのはどういった理由ならやら。

[ ]
RE:07814 ファイル名の認識No.07817
bouz さん 05/05/18 14:22
 
ああ。
> そうはいっても、単純にあげると誤認識も増えるので。
認識しないのも誤認識と思えば、差し引きゼロです。

>を読んで思い出したのですが、JAVA だと確かにクラスのことを考えると、
>「ファイル名と思わしき場所」で処理しようとすること自体無理か有る気がし
>ます。

java のソースでは、オフるのが常識ですよね?
そもそも記述法が決まっているファイルに対して、自由度を求めることこそ、無理が
ある気がします。

使い物にならないとは、つまりファイル名以外が表示されてウザいので、
正真正銘のファイル名と思わしき場所を機能させて使いたいけどオフんなきゃいけな
いので、使えないってことですか?

>と同様のことを減らすために、現在の仕様になっている、というだけの事だと
>思います。
また勘違いされてるし。(^_^;)
秀丸が認識しない必要なファイル名がすべて強調されました。ってことで
javaのソースみたいなえらいことになった、ってことじゃないです。

>[A-Za-z:./\\_]+\.[A-Za-z][A-Za-z0-9]{0,3}
>かな。
頭は (ほげ)?のほうがいいでしょうね。いずれにせよこれでは無理です。

> 私は「.」の扱いより寧ろ、「,」の扱いが解りません。
>a.txt, b.txt をコピー

ええっとですね、想像なんですけど。秀丸のファイル名解析は、
.が現れるとファイルの拡張子が始まったと見なすんですねきっと。
そしてそれに続く文字を見ている。
'や"や#だとその前で、空白とかタブとか改行とかが現れると、そこで拡張子が完結。
それ以外の文字が現れると、ファイル名としての解析そのものがクリアされるわけで
す。大体の話ですよ。
で、ファイル名とか拡張子とか見なすのが、a-z0-9なんですよ。
.も,も入ってない。だから、ファイル名解析ルーチンを抜けるわけです。
で、ボクが言っているのは、この[a-z0-9]に . を加えてみたらどうですか?
という提案なんですよ。
Iranoanさんが , も欲しいというなら、 , も加えればいい話です。
高々1バイト程度の話で、肥大化とか副作用とか心配しすぎです。
でも想像なんで、はずれてるかもしれません。が、秀丸担当さんのバランス感覚から
して、こんなとこに膨大なコード書くことはないでしょうから、少なからず、という
気が。

で、元々このスレッドは、ネタ的ですが、と言って、スムーズブレーキなどと併記し
ているので、どうしても入れてくんなきゃいやだぁ、ボク入れてもらうまで、ここ動
かない、
って言ってるわけでもないんですけどね。(^_^;)

秀丸が時代遅れにならないように、という仄めかしなんです。
思うに、秀まるおさんか、秀丸担当さんかcygwinかなんかでも使ってくれれば、すぐ
入るんじゃないかとさえ思っています。(^^)

だからレスが付くのが意外でした。でもこれは裏返して言うと、みんながこの件に関
して何か問題意識を持っていることの現れでしょうから、
この際要求としてまとめてみると、

ファイル名として認識する文字の追加文字列を定義できるようにする。(禁則文字の
ような)

java のコードでは、矛盾しないようにコードを優先させるオプションを設ける。

っていう感じですかね。スタンスはネタですよ、ネタ。渇望はしていません。秀丸担
当さんの気の向くままに、です。

最後に一言。
進化はカオスの縁で生まれる。秀丸はオンラインソフト。箱入りがんじがらめのソフ
トとはわけが違う。専門のテスターもいないみたいだし、僕らでテストしなきゃしょ
うがない。進化を捨てるのであれば、近付かなければいいのだし、進化したいと思う
ならば、カオスに身を投じなければならない。もちろん、付けなきゃならない折り合
いは山ほどあるでしょうけど。

[ ]
RE:07817 ファイル名の認識No.07818
M.D.S.-Toy さん 05/05/18 16:01
 
うーん・・・。


>> そうはいっても、単純にあげると誤認識も増えるので。
>認識しないのも誤認識と思えば、差し引きゼロです。

過剰に認識してもかまわないというbouzさんのような方もいるでしょう。誤認識が増
えるとわずらわしく思う人もいるでしょう。
わずらわしく思う人が出る時点で単純に差し引きゼロということにはならないと思い
ますが。


>ええっとですね、想像なんですけど。秀丸のファイル名解析は、
(中略)
>で、ファイル名とか拡張子とか見なすのが、a-z0-9なんですよ。
>.も,も入ってない。だから、ファイル名解析ルーチンを抜けるわけです。
>で、ボクが言っているのは、この[a-z0-9]に . を加えてみたらどうですか?

"a.a.a" はファイル名と思わしい場所になりますし、"a.1" はなりませんから、この
推測は間違っていますね。


>だからレスが付くのが意外でした。でもこれは裏返して言うと、みんながこの件に
>関して何か問題意識を持っていることの現れでしょうから、

僭越であることを重々承知の上で、この際はっきりいいますが、私は問題意識という
か危機感を持っているのでレスを付けたのです。

なぜなら
>スタンスはネタですよ、ネタ。渇望はしていません。秀丸担当さんの気の向くまま
>に、です。
とてもそうは思えない(見えない)からです。
また、bouzさんの主張は自分の環境しか見ていないことが明らかだからです。


>進化はカオスの縁で生まれる。秀丸はオンラインソフト。箱入りがんじがらめのソ
>フトとはわけが違う。

ソフトの性質を決めるのはサイトー企画の方だと思うのですが。

(進化したいと思うならば、カオスに身を投じなければならない。という主張は間違
ってはいないと思います。
が、秀丸がどういう道をたどるかはまた別の話ではないかということです。そしてそ
れは一ユーザがどうこう言うべきではないということです。)


無論私のこの書き込みも大きなお世話ではありますがね・・・。

[ ]
RE:07814 ファイル名の認識No.07820
shino さん 05/05/18 19:48
 
思いつきで申し訳ないのですが。

私の場合、「ファイル名と思わしき場所」にチェックをするのは、テキストファイル
やHTMLファイルなどだけです。
Javaファイルにチェックすると、パッケージ名がファイル名と認識されソースが見づ
らくなるのでoffにしています。

妥協案としての提案です。
ファイルタイプ別の設定に次のような設定があると便利かと思いますが、どうでしょ
う。
1.ファイル名と認識する拡張子
 例えば、.txt;.html;.javaなどを登録しておくと、それ以外は認識しない。
2.ファイル名の段階的な厳密化
 例えば、
 ・現状通り
 ・ファイル名に許される半角英数(スペース含まず)
 ・ファイル名に許される半角英数(スペース含む)
 ・ファイル名に許される全ての文字列
 という選択肢から選べるようにする。

解析の速度などの問題もあるでしょうが、「現状のファイル名の認識は甘すぎる」
「厳密に認識するとご認識が増え見づらくなる」という問題の間を取る案だと思いま
す。
# どうしても実装してくれ、というわけではありません。

[ ]
RE:07818 ファイル名の認識No.07823
bouz さん 05/05/18 21:50
 
こんばんは。
Iranoanさんにいっぱいツッコミ入れてもらえると思っていたのに。(^^)

危機感ってなんですか?全く解りません。
レスされるのでしたら、少なくともボクにわかるように具体的に書いてください。お
願いします。
そしてそれが秀丸の進化に関してあまり建設的でないのならばご勘弁を。

> そしてそれは一ユーザがどうこう言うべきではないということです。

それが一晩考えてのあなたの意見?
ならばあなたもとやかく言うべきではないと思いますが(^_^;)。自己矛盾です。危機
感とも矛盾してる。

過剰認識したらそりゃボクだって困りますよ。でもこれはβテスト。もっともっとい
ろんな意見が出て当然でしょう。
秀丸とATOK以外は海外ソフトですが、βテストどころかリリースされてもこんなもん
じゃないです。
ああしてくれこうしてくれ、こんなのも、こんな環境もサポートしてくれ。でもここ
は日本。
ボクなりに遠慮しいしい書いてますよ。要望の10分の1も出してない(笑)。
やってダメなら、即オフればいいじゃないですか。何も目くじらたてなくたってその
ためのβテストなんじゃないんですか?

そして秀丸担当さんの話から、わざわざはじいているというのでじゃ試しにはじかな
いでやって
みてくれ、と言ったのは、全然ローコストで見返りが大きいと考えてのこと。それは
ボクの判断。
やるやらないを決めるのは開発サイドの判断。それ自体についてとやかく言う必要が
ないのはあなたが書いているとおりです。

しかもそれで解決されるであろう問題は、個人的にはもうアルビレオさんのアドバイ
スで解決しているので
全く建設的意見だと思っていただかないと。

開発者側をかばうようなスタンスに見えますが、それが本当に開発側の励みになるで
しょうか?
ユーザ拡大につながるでしょうか?
既存ユーザの秀丸離れを防ぎ、新規ユーザも増えてくれなければ、結局困るのはボク
たち既存ユーザです。

カオス云々について同意されるのでしたら、わかってもらえると信じます。

そういう一ユーザの声に、わざわざ物申す、って重箱の隅つつかれても言い様がない
です。
みんな自分の環境しか見れません(笑)。少なくともボクはあなたに
自分の環境を見てもらった覚えはないです。

こんなのできたよほーらみんな見てご覧、と舞台上で大上段に構えてウケるような時
代はとっくの昔に過ぎたんです。
作る側が積極的に客のほうに自ら身を投じなれば廃れるんです。
だからこの会議室があっていろんな要望が出てものすごい勢いで改良されていく。
とてもラッキーなことだと思いますけど。

[ ]
RE:07823 ファイル名の認識No.07824
カモノハシ さん 05/05/19 00:36
 
そう語気を強くしなくても(汗)

> > ##私も個人的にはディレクトリ名に「.」があっても良い気がしますが...。
> そうでしょ?ですよね〜。なぜ執拗に抵抗されるか解らない。
に対する答えとしては
> もちろん、本来ファイルとして記述したのでないもの、たとえば
> 1.2/1.3
> とかいう文字も強調されてしまいましたが、別にどうってことない。
別にどうってことない、とは考えない人もいるからだと思います。
例えば、
************************************
Q 拡張子でコンパイルモードが変わる?
A その通りです。例:hoge.c/hoge.cpp 前者はCモードで後者はC++モードです。
************************************
っていうようにファイル名を列挙するときに「/」で区切る人はままいると想像でき
ます(私もたまにやります)。
「ファイル名なら空白入れてつながらないように」というのは正論ではありますが…
…上と同様に習慣だといわれてしまえば、それだけのことではあります。

他の方も書かれていますが、
・ファイル名として強調表示されないので不便
・余計な文字列までファイル名として強調されて不便
のトレードオフですよね。
別に皆さん要望を出すことを否定しているわけではなく、その要望が採用されると自
分の望んだ(又は多数が期待すると考える)動作でなくなってしまうので、サイトー企
画さんにたいして意思表示をしているわけです。
(と、私は考えています)

で、本題の私のですが(汗)
バックスラッシュ「\」区切りの時には「.」を入れても良いんじゃないのかな?
と思っています。\でファイルを列挙はあまり一般的でないと思いますから。
もちろんカスタマイズ出来るようになるならまた別の話ですが(もちろんこれに対し
てもオプションが増えすぎてややこしいからって意見もあります)。
もしくは表示モードによって判定を振り分けても良いと思います。
私は「.」つきのディレクトリも上記のような文字列も両方使うことがあるので悩ま
しい限りです(汗)

肝心のbouzさんの問題にしている文字列は漏れますが、「/」で区切って「.」を含む
ディレクトリを利用する人はある程度以上のスキル/経験がある人だとおもいますから、
ご自身で試されているように強調表示/マクロを使って対処、でもしょうがないかな
と考えます。
(ヘルプにその代案が書かれているとなお良い。)

[ ]
RE:07820 ファイル名の認識No.07825
Iranoan さん 05/05/19 00:42
 
 秀丸担当さん、shino さん今日は、Iranoan です。
> ファイルタイプ別の設定に次のような設定があると便利かと思いますが、どうでしょ
> う。
> 1.ファイル名と認識する拡張子
>  例えば、.txt;.html;.javaなどを登録しておくと、それ以外は認識しない。
 これを読んでいて思ったのですが、もっと単純に拡張子として許す文字数に
制限 (4 文字以内など) があっても良いのではないでしょうか? そして、こち
らで制限をつければ、他の部分を緩くしても随分誤認識は減ると思います。

[ ]
RE:07817 ファイル名の認識No.07826
Iranoan さん 05/05/19 00:42
 
 bouz さん今日は、Iranoan です。
 私信で請求されてしまったので、一応こちらに書き込みます。
 ##実はその私信がスパム判定になっていて、ゴミ箱に埋もれていました(^^)。
←冗談みたいな本当の話。

> > そうはいっても、単純にあげると誤認識も増えるので。
> 認識しないのも誤認識と思えば、差し引きゼロです。
 これ以外にも、意見が異なっていたり、誤解されていることがありますが、
一々回答する自分の行為が馬鹿馬鹿しくなったので、止めます。←これではキ
ツいので書き直すと、一体何のための回答か、目的が解らなくなった、と。何
故なら、そもそも ``「.」はフォルダ名として許しても良いのではないか''
という基本部分は、私も同じなので(^^)。

[ ]
RE:07820 ファイル名の認識No.07827
アルビレオ さん 05/05/19 02:51
 
アルビレオです。

>1.ファイル名と認識する拡張子
> 例えば、.txt;.html;.javaなどを登録しておくと、それ以外は認識しない。

これはすでに「ファイルタイプ別の設定」で実現していることですよね。
新規インストールの初期状態を確認できないですが、確かファイルタイプ「C言
語ソースファイル」の初期状態は「ファイル名と思わしき〜」はOFFになってい
たと思います。
だからいまさらこういう機能を追加するのは混乱を招くだけでしょう。


○ここからは「拡張子付きディレクトリ名の認識」に反対している方全員へ

そもそもCやjavaでは abc.def といった「ファイル名でない文字列」はいくらで
も出てくるので「ファイル名と思わしき〜」がOFFでないと使い物になりません。
だからCやjavaの例を持ち出して拡張子付きディレクトリ名を認識するようにし
たことで今よりも困る状況が起きるというのは考えにくいのではないでしょうか。

カモノハシさん
>A その通りです。例:hoge.c/hoge.cpp 前者はCモードで後者はC++モードです。
>************************************
>っていうようにファイル名を列挙するときに「/」で区切る人はままいると想像でき
>ます(私もたまにやります)。

確かにたまにやってしまいますが、単なるテキストであればファイル名扱いされ
ても特に困るわけではないような。
Windwosにおいても「/」をパスの区切り文字として扱うことは十分に一般化して
ますし、それ以外の意味として(途中にに空白も開けずに)「/」を使っていれば
そういうテキストを書いた側が悪いとしても理不尽ではないと思います。
/hoge.c
src/hoge.c
hoge.abc/hoge.c
のうち、3つめだけはファイル名扱いしない、としなければ困る状況ということ
があるのかなぁと。

>> もちろん、本来ファイルとして記述したのでないもの、たとえば
>> 1.2/1.3
>> とかいう文字も強調されてしまいましたが、別にどうってことない。
>別にどうってことない、とは考えない人もいるからだと思います。

今の秀丸はピリオドの直後に数字があれば「小数点の可能性が高い」としてファ
イル名扱いしないルールになっているようです。
だから「1.0E6」のような指数表記でもファイル名と誤認されることはほとんど
ありません。
これは今回の要望を採用しようがしまいが同じことなので、数値を誤認する可能
性については議論しても無意味でしょう。

私は拡張子付きディレクトリ名はそれほど一般的ではないということで気分的に
は要望に賛成する気にはなれませんでしたが、だからといって具体的に「困る
例」をあげることもできないので賛成も反対もしませんでした。
で、今までの流れを見ると反対している方があげている「困る例」にはいまひと
つ説得力がないように思えます。

何を言おうが最終的には秀丸担当さんが決めることですが、反対するならもっと
他の例を出してきた方がいいのではないでしょうか。

bouzさん
>危機感ってなんですか?全く解りません。
仕様変更が決まってから、今まで簡単にできていたことがすごくめんどくさくな
ったり、うまく動かないマクロが出てきたりしたら途方に暮れるほど困ってしま
って、秀丸を使うことをあきらめる人がいるかもしれません。
だから長く使っている人ほど自分が途方に暮れないために「この変更で自分が困
ることはないだろうか?」と想像力をフル回転させてあらさがしをするんです。
決まった後になってから「困るから元に戻して」といわれるよりは、問題がない
かを今の時点からチェックしてくれている、と受け取った方がいいんですが…
私の場合は反対論を見て「この程度なら問題ないかも?」と思い始めたくらいで
すので(笑)

[ ]
RE:07824 ファイル名の認識No.07828
bouz さん 05/05/19 11:44
 
動物占いではコアラのbouzです。おはようございます。
いやいや失敬。見るに見かねたんですね。

>別にどうってことない、とは考えない人もいるからだと思います。
見た目で困るってことなら、区別は付くけど目立たないようにすればいいだけで
それ以外の実害はないってことでいいですよね?

>バックスラッシュ「\」区切りの時には「.」を入れても良いんじゃないのかな?
>と思っています。
ひとり賛同者が現れました。ありがとうございます。

>「/」で区切って「.」を含むディレクトリを利用する人はある程度以上のスキル/経
>験がある人だとおもいますから、
そんなでもないと思うんですけどね。そんなに一般的じゃないことでしょうか。

[ ]
RE:07826 ファイル名の認識No.07829
bouz さん 05/05/19 11:46
 
おはようございます。呼び出しましたよ〜。
だって出てきて欲しいときに出てこないから。でも来てくれましたね。ありがとう。

> ##実はその私信がスパム判定になっていて、ゴミ箱に埋もれていました(^^)。
>←冗談みたいな本当の話。
なんで相方のメールをごみ箱に突っ込むの、と突っ込んでみる。

>一々回答する自分の行為が馬鹿馬鹿しくなったので、止めます。←これではキ
>ツいので書き直すと、一体何のための回答か、目的が解らなくなった、と。何
>故なら、そもそも ``「.」はフォルダ名として許しても良いのではないか''
>という基本部分は、私も同じなので(^^)。
だったらはじめからそういうスタンスで統一してくださいよ。(^_^;)
全然きつくないです。ボクに対してはそれくらいでいいですよ。(^^)
でまたひとり賛同者が現れました。

[ ]
RE:07825 ファイル名の認識No.07830
bouz さん 05/05/19 11:47
 
> これを読んでいて思ったのですが、もっと単純に拡張子として許す文字数に
>制限 (4 文字以内など) があっても良いのではないでしょうか? そして、こち
>らで制限をつければ、他の部分を緩くしても随分誤認識は減ると思います。
これはどうかなぁ。文字数だとまたフラストレーションたまりそう。

[ ]
RE:07827 ファイル名の認識No.07831
Iranoan さん 05/05/19 11:52
 
 アルビレオさん今日は、Iranoan です。
> >1.ファイル名と認識する拡張子
> > 例えば、.txt;.html;.javaなどを登録しておくと、それ以外は認識しない。
>
> これはすでに「ファイルタイプ別の設定」で実現していることですよね。
 何処で?
> 新規インストールの初期状態を確認できないですが、確かファイルタイプ「C言
> 語ソースファイル」の初期状態は「ファイル名と思わしき〜」はOFFになってい
> たと思います。
 確かに OFF になっていたと思いますが、「ファイルタイプ別の設定」で
ファイル名の認識にと関係するのは、「ファイル名と思わしき〜」の ON/OFF
とその修飾方法の設定だけで、拡張子の設定は何処にもないと思いますが...。
 少なくとも私の環境では、hoge.hogehogehogehoge がファイル名として認識
されてしまいますが、こんな拡張子は初期設定されていないでしょうし、何処
かで設定した記憶もありません(^^)。
 こちらの環境は、WindowsXP+IE6.0+秀丸 Ver.5.00β15 です。

[ ]
RE:07827 ファイル名の認識No.07832
bouz さん 05/05/19 12:00
 
おはようございます。レスありがとうございます。
>>1.ファイル名と認識する拡張子
>> 例えば、.txt;.html;.javaなどを登録しておくと、それ以外は認識しない。
>だからいまさらこういう機能を追加するのは混乱を招くだけでしょう。

最初見たときなかなかいいかな、と思いましたが、使う物を全部入れなきゃならない
のが
煩雑だし、たくさんいれるとパフォーマンス低下を招くかもしれない。
それ以外の部分が今のままだと。

>だからCやjavaの例を持ち出して拡張子付きディレクトリ名を認識するようにし
>たことで今よりも困る状況が起きるというのは考えにくいのではないでしょうか。

全く同感です。そんなこと当たり前だと思って書かなかったんですが。まとめてくだ
さいました。

>確かにたまにやってしまいますが、単なるテキストであればファイル名扱いされ
>ても特に困るわけではないような。
>Windwosにおいても「/」をパスの区切り文字として扱うことは十分に一般化して
>ますし、それ以外の意味として(途中にに空白も開けずに)「/」を使っていれば
>そういうテキストを書いた側が悪いとしても理不尽ではないと思います。

だから困るという人はいったい何が困るのかと。
ここは全く同意見ですが、

>/hoge.c
>src/hoge.c
>hoge.abc/hoge.c
>のうち、3つめだけはファイル名扱いしない、としなければ困る状況ということ
>があるのかなぁと。

これではあまりやる意味がないように思います。

>今の秀丸はピリオドの直後に数字があれば「小数点の可能性が高い」としてファ
>イル名扱いしないルールになっているようです。
>だから「1.0E6」のような指数表記でもファイル名と誤認されることはほとんど
>ありません。

ああ、これは見落としていました。こういうのをたくさん指摘して欲しいのです。

>これは今回の要望を採用しようがしまいが同じことなので、数値を誤認する可能
>性については議論しても無意味でしょう。

同感ですが、ファイル名として認識して欲しい、というスタンスです。
繰り返しになりますが、オフれるオプションがあるのだから、余計に出る分には
ユーザの意識で変えられる。例えば改行とかタブとかの表示を切り替えることが秀丸
ではワンキーでできる。
同じようにファイル名の表示もワンキーで切り替えることが出来る。

でも認識はユーザ側ではどうしようもない。
だからリーズナブルな範囲でできるだけファイル名属性は増えていた方がよい。とい
う意見です。

>で、今までの流れを見ると反対している方があげている「困る例」にはいまひと
>つ説得力がないように思えます。
>何を言おうが最終的には秀丸担当さんが決めることですが、反対するならもっと
>他の例を出してきた方がいいのではないでしょうか。

そうなんですよ。ちょっと考えたんでは思いつかない。

で、ようく考えてみると、
例1. Aさんが、仕事であるファイルに対してマクロを実行する。
そのファイルは次のような形式。
1行目> ファイル名 work1.dat
2行目> データ 1.0/1.1/1.2
4行目> ファイル名 work2.dat
3行目> データ 2.0/2.1/2.2
で、そのマクロは、最初ファイルの先頭に跳び、colorcode:21 (ファイル)の文字列
をサーチする。
そのファイルと何かやり取りする。
そして次のファイル文字列が現れるか、EOFまではデータの処理を続ける。
こんな物でしょうか。これだとこのマクロはデータの区切りをまるっきり colorcode
に頼っていることになるから、
データ部分がファイル名になるとまずい。
しかし、そんなマクロをクリティカルな局面で運用しているケースが本当にあるのだ
ろうか?
もし、仮にあったとしても、βテストが行われているのだから、次期バージョンが出
る前に
確かめてみることくらい、運用する側の責任として当然ではないのか?

もうひとつは
例2. Aさんが例1.のファイルの2行目以降のデータがめたくそ長いファイルを眺めて
いる。
1行目のファイルをオープンするアプリケーションは登録してある。だからここはフ
ァイル名として認識させておく。
Aさんは、データ部分が全部ファイル名として表示されているのを
突如目の当たりにしてしまう。
オッケー。何の問題もない。見づらければ、色でも何でもカスタマイズできる。
普通の文字と全く同じ表示で、裏にはファイル名としての属性を持たせることだって、
出来る。
それも厭だとわがままいうなら、解決策は後述。

>bouzさん
>>危機感ってなんですか?全く解りません。
>仕様変更が決まってから、今まで簡単にできていたことがすごくめんどくさくな
>ったり、うまく動かないマクロが出てきたりしたら途方に暮れるほど困ってしま
>って、秀丸を使うことをあきらめる人がいるかもしれません。
>だから長く使っている人ほど自分が途方に暮れないために「この変更で自分が困
>ることはないだろうか?」と想像力をフル回転させてあらさがしをするんです。
>決まった後になってから「困るから元に戻して」といわれるよりは、問題がない
>かを今の時点からチェックしてくれている、と受け取った方がいいんですが…

まぁ、漠然としたそういう思いについては、解らないでもないです。でも、はっきり
根拠を書いてくれないと、
何が言いたいのと言われても仕方ないでしょう。なにもあなたの娘さんをボクにくだ
さい、って言ってるんじゃない、
βテストしてるだけなんだから、みんなで活用すればいい。

途方に暮れるのはβ版をいきなり業務に使って仕様が変わったのに気付いたときくら
いでしょう。
それはユーザ側の問題だと思います。

ボクが危惧するのはそんなのよりも、ある職場で先輩が後輩に秀丸を勧める。
初めて秀丸に触れた若者は、変な名前だな、とか思いながらも単なるエディタじゃな
いな、と徐々に気付く。
ところがある日、いつものように記述されている work/siji.txt というファイルを
クリックしようとしたら、
リビジョンがついて work.1/siji.txt に変わっている。あれ、なんで開かないの?
仕方ないので別のやり方でオープン。
いろいろ調べてそれが仕様だと解る。
「うわ、だっせぇ〜」たった .1 という文字が付加されただけで開けなくなったこの
エディタの印象を若者は何かの折りに触れて回る。
悪評はさっさと広まり、他に素晴らしい機能が
あるにもかかわらず、ダサいという烙印が押されてしまう。

で〜、長かったですが、これまでちゃんとレスしてくれた方々の見解をまとめると、
.〜はディレクトリ名に入れても良いのではないか。という声なき声?は確かにある。
しかしもろもろの事情を考えて、だれも絶対そうしてくれ〜とは言えない。ボクも含
めて。

そこで、ひとつのアイディアですが、カーソル行に対してだけファイル名と思わしき
場所を.も含めて表示するオプション。
というのはどうですかね?ダメかなぁ。きっとダメだなぁ。

>私の場合は反対論を見て「この程度なら問題ないかも?」と思い始めたくらいで
>すので(笑)
またひとり賛同者が現れた、と見なして良いのでしょうか。
そうなるのが当然だと思います。私だってそうですから(笑)。もう個人的には片づい
ているので、
反対論の人が具体例を挙げてくれれば、あ、そうですね。わかりました、とひっこめ
て何の不都合もないんですが、
そうじゃないからいくらでも新たなアイディアを提示せざるを得ない。という感じで
す。

繰り返しますが、ネタですよ、ネタ。

[ ]
RE:07832 ファイル名の認識No.07833
M.D.S.-Toy さん 05/05/19 12:08
 
とりあえずひとつ事実誤認がありますんで指摘しておきます。

>まず、個人的には"."がフォルダ名から除外されるのは確かにどうなのかなと思って
>います。"."入りのフォルダ名がそんなにイレギュラーなものだとも思いませんし。

私は賛成派ですよ。

[ ]
RE:07831 ファイル名の認識No.07834
アルビレオ さん 05/05/19 13:28
 
アルビレオです。

>> 新規インストールの初期状態を確認できないですが、確かファイルタイプ「C言
>> 語ソースファイル」の初期状態は「ファイル名と思わしき〜」はOFFになってい
>> たと思います。
> 確かに OFF になっていたと思いますが、「ファイルタイプ別の設定」で
>ファイル名の認識にと関係するのは、「ファイル名と思わしき〜」の ON/OFF
>とその修飾方法の設定だけで、拡張子の設定は何処にもないと思いますが...。
> 少なくとも私の環境では、hoge.hogehogehogehoge がファイル名として認識
>されてしまいますが、こんな拡張子は初期設定されていないでしょうし、何処
>かで設定した記憶もありません(^^)。

と、勘違いしてました。
開いているファイルの拡張子ではなく、テキストに書かれた文字列に対して登録
した拡張子以外のものはファイル名扱いしない、という意味だったんですね。

うーん、たいしたことはないかもしれないけど今よりは確実に遅くなりそうだし、
ある程度初期設定で登録されているとしても自分で追加しなきゃいけないものは
多そうだし、設定項目が増えてしまうし…
ダメってことはないけど、あまり支持する気にもなれない案ですねぇ。

[ ]
RE:07832 ファイル名の認識No.07836
アルビレオ さん 05/05/19 14:04
 
アルビレオです。

>ボクが危惧するのはそんなのよりも、ある職場で先輩が後輩に秀丸を勧める。
>初めて秀丸に触れた若者は、変な名前だな、とか思いながらも単なるエディタじゃな
>いな、と徐々に気付く。
>ところがある日、いつものように記述されている work/siji.txt というファイルを
>クリックしようとしたら、
>リビジョンがついて work.1/siji.txt に変わっている。あれ、なんで開かないの?
>仕方ないので別のやり方でオープン。
>いろいろ調べてそれが仕様だと解る。
>「うわ、だっせぇ〜」たった .1 という文字が付加されただけで開けなくなったこの
>エディタの印象を若者は何かの折りに触れて回る。

はい反論。
数字のみの拡張子をファイル名扱いすれば、小数点つきの数値をファイル名とし
て認識してしまい「うわ、だっせぇ〜」と思われてしまうことの方が間違いなく
多いでしょう。
はっきりいって「迷惑な仕様変更」です。
だったらピリオドの前が数字かどうかも判定すればいいわけですが、「ピリオド
の後ろが数字だったらピリオドより前が全部数字かどうか調べなおして…」とい
うのは時間がかかりそうなので難しいところですね。

まあファイル名に空白や日本語文字などを含んでいる場合も考えれば、どうせフ
ァイル名を取りこぼさずに認識するのは無理なんですよ。
だから慣れてくると秀丸のファイル名認識には頼らずに「範囲選択して開く」と
いった手段を使うようになります。
そういうこともあってファイル名認識範囲の中途半端な拡大なんて、それほど便
利になるとは思えないんですよ。
私は今のところ「使い勝手は大して変わらないと思うけど、問題は少なそうだか
らやってもいいかもね」というスタンスなので (^^;

[ ]
RE:07834 ファイル名の認識No.07842
Iranoan さん 05/05/19 17:31
 
 アルビレオさん今日は、Iranoan です。
> と、勘違いしてました。
 やっぱりその様な設定はないですよね。
> うーん、たいしたことはないかもしれないけど今よりは確実に遅くなりそうだし、
 体感速度としてはそれほど変わらないと予想しています。何故なら強調表示
で複雑な正規表現を駆使しても遅いという実感がなかなかないので。また遅く
なる環境なら、他の設定同様 OFF にもできますし。

> ある程度初期設定で登録されているとしても自分で追加しなきゃいけないものは
> 多そうだし、設定項目が増えてしまうし…
 それはそうですね。
 ただ既に「動作環境」の「ファイル」に「最初のワイルドカード」があるの
で、多くの人はそれを C&P すれば済む気がします。
 もちろんそれも上手くいかない人も居ると思うので、
> 単純に拡張子として許す文字数に
> 制限
と思った次第です。パスの一部ではなく本来のファイル名の拡張子ならそれほ
どの文字数は使わないでしょうから。

[ ]
RE:07836 ファイル名の認識No.07843
bouz さん 05/05/19 21:15
 
>はい反論。
>数字のみの拡張子をファイル名扱いすれば、小数点つきの数値をファイル名とし
>て認識してしまい「うわ、だっせぇ〜」と思われてしまうことの方が間違いなく
>多いでしょう。
>はっきりいって「迷惑な仕様変更」です。

そうですか?
オンにしているのがおかしいと思ってしまいます。
java のソースと同じくずっ〜とオンにしたまま使わないでしょう。
たぶん、数字ははじかれるままになるでしょうし。
見た目の問題なら、オフればいいのでは。そうすれば持続しない。
機能の問題として、必要なときにはできるだけ、っていう考えなんですけどね。

だれもそんなに便利になるなんて思ってないです(笑)。
バランス的に.~くらいはそろそろ認識しといても悪くないんじゃないの、って話です
よね。

[ ]
RE:07842 ファイル名の認識No.07844
bouz さん 05/05/19 21:37
 
この方式は、確かに誤認識は激減するのがとても魅力的ですね。

[ ]
RE:07843 ファイル名の認識No.07845
アルビレオ さん 05/05/19 21:53
 
アルビレオです。

>>数字のみの拡張子をファイル名扱いすれば、小数点つきの数値をファイル名とし
>>て認識してしまい「うわ、だっせぇ〜」と思われてしまうことの方が間違いなく
>>多いでしょう。
>>はっきりいって「迷惑な仕様変更」です。
>
>そうですか?
>オンにしているのがおかしいと思ってしまいます。

うーん、別にソースファイルとかの話じゃなくてごく一般的なテキストの中では
「ファイル名」も「小数点つきの数値」も普通に出てくると思うのですが。
「普通のテキストファイル」でONにしっぱなしっておかしいですか?

>java のソースと同じくずっ〜とオンにしたまま使わないでしょう。

いや、ファイルタイプごとにONかOFFを設定してずっとそのままという使い方を
する人の方が多いと思いますよ。

>たぶん、数字ははじかれるままになるでしょうし。

ちょっとわからなかったのですが、これは
・ピリオド直後が数字の文字列をファイル名扱いしても、数字ははじかれたまま
・今回は「ピリオド直後が数字」の扱いは変更されない
のどっちの意味なんでしょうか?

前者だとすれば、なぜ数字ははじかれるのかわからないし
後者だったら流れ的にちょっと唐突でわかりにくいです (^^;

[ ]
RE:07845 ファイル名の認識No.07846
bouz さん 05/05/19 22:23
 
>うーん、別にソースファイルとかの話じゃなくてごく一般的なテキストの中では
>「ファイル名」も「小数点つきの数値」も普通に出てくると思うのですが。
>「普通のテキストファイル」でONにしっぱなしっておかしいですか?

いや全然おかしくないですよ。ONです。
データファイルの話かと思ったんですよ。
でもそれは今だって完璧じゃないから、そんなに気になります?

>
>>java のソースと同じくずっ〜とオンにしたまま使わないでしょう。
>
>いや、ファイルタイプごとにONかOFFを設定してずっとそのままという使い方を
>する人の方が多いと思いますよ。
>
全く同じこと言ってるんですけど。(^_^;)

>ちょっとわからなかったのですが、これは
>・ピリオド直後が数字の文字列をファイル名扱いしても、数字ははじかれたまま
>・今回は「ピリオド直後が数字」の扱いは変更されない
>のどっちの意味なんでしょうか?
>
>前者だとすれば、なぜ数字ははじかれるのかわからないし
>後者だったら流れ的にちょっと唐突でわかりにくいです (^^;

後者です。
秀丸担当さんはやらない、と言っているので、可能性は低いんですが、もしやるとし
てもたぶんはじかれるだろうと思ったということです。
なぜなら、ボクはアルビレオさんが指摘した、小数点優先というのを
まったく見過ごしていたからです。小数点と、数字拡張子のどちらを
優先するかと言えば、間違いなく小数点だと思うからです。

その話と、仮に小数点を拡張子と認識した場合の話は、また別ですよ。
その場合は、ユーザ自身が、数字付き拡張子を(結果を知っているにしろ知らないに
しろ)
ONにして表示したわけだから、オフにする選択肢があるので、秀丸が即ダサい
と言いきることは出来ないんじゃないか、ということです。
伝わったでしょうか?

[ ]
RE:07845 ファイル名の認識No.07848
bouz さん 05/05/19 23:16
 
とどのつまりが、ダサいなと思う箇所への比重のかけ方が違うってことみたいですね。
どうも。
ボクがそう思うのは、実際に存在するファイルを、わざわざ書いているのに、認識し
てくれない。そこで決定的に思うわけです(存在確認はしなくていい)。
多少余分に出てくれるくらいを期待してる。ファイルによって、目障りなくらい出て
きたら、オフればいい。それでダサいとはあまり思わないし、誤認識とさえ思わない。
なぜなら書式が合っているんだから。むろん存在確認すればはじかれますが、それは
望まない。
必要なときに、表示されたそれらの中から、ユーザが選ぶか、あるいはマクロで処理
するかすればよい。
そのためには可能性のある候補がもれないでほしい。
とこういうことなんですね。

これに対して、別の意見はそうじゃない。余計に表示された時点で、ダサい、使えな
い。誤認識だろうとなる。
でもこれは誤認識というより書式が合っているだけの話で、実際にアクションを起こ
すまでそれは言えない。
なぜなら、データの中の1.2というファイルが、本当にあるかもしれないからです。

存在確認をせずに表示されているわけだから、いわば変換前の変換候補みたいなもの
で、候補に挙がらなければ、変換できないじゃないか、っていうのが一貫して言って
ることなんです。

しかしこういう受け取り方が一般的なユーザに向けて通用するかどうかは解りません。
ここでこれだけ手間がかかる、ということは、おそらく通用しないんでしょう。
たぶん、存在するかもしれないファイルの候補ではなくて、アルビレオさんが教えて
くれた
file:〜と同次元のものとして受け取られるでしょうね。両者は性質が全く違うのだ
けれど。

[ ]
RE:07848 ファイル名の認識No.07849
アルビレオ さん 05/05/20 00:43
 
アルビレオです。

>とどのつまりが、ダサいなと思う箇所への比重のかけ方が違うってことみたいです
>ね。

というか、ユーザー層の問題ですね。
平均的なWindowsユーザーなら拡張子が数字のファイル名より小数点つきの数値
の方が出てくる頻度が高いだろうし、拡張子が数字のファイルを扱うようなユー
ザーなら多少手間がかかっても代替手段は思いつける可能性は高いだろうし。
あまり複雑な使い方をしない/できないユーザーが混乱しないようにしておいた
方がゴチャゴチャ言われる可能性は減らせると思います。

どうせ"Program Files"や"マイ ドキュメント"は認識できないのだから、拡張子
が数字のファイル名を認識しても、その違いに気づく機会はそう多くありません。
でも小数点付きの数字ならライトなユーザーでも目にすることはいくらでもあり
ます。
そのあたりのトレードオフを考えると拡張子が数字のファイル名は切り捨てた方
が自然な選択ではないかと思っているわけです。

[ ]
RE:07849 ファイル名の認識No.07927
秀丸担当 さん 05/05/27 17:05
 

特にコメントせずにβ24,25で機能を追加してしまいましたが、ファイル名と思
わしき場所などを正規表現でカスタマイズできるようにしてみました。

かんばしくないようでしたら無くすかもしれないですが。
誰も気付いていない気がしたので…

[ ]
RE:07927 ファイル名の認識No.07929
bouz さん 05/05/27 17:14
 
>
>特にコメントせずにβ24,25で機能を追加してしまいましたが、ファイル名と思
>わしき場所などを正規表現でカスタマイズできるようにしてみました。
>
>かんばしくないようでしたら無くすかもしれないですが。
>誰も気付いていない気がしたので…

すいません。気付いてます。なくさないでください(笑)。
一言で言ってすばらしいオプションだと思います。
悩む人、悩みたくない人、どちらにも対応してる。

さっそく試してみたところ、思っていた以上の効果がありました。
前バージョンまでで、見た目上へんだったのがことごとくクリアです。
おまけに
C:\Program Filesとかもいれられるので、環境変数も必要ないです。

file:に合わせて書き換えていた自前のタグジャンプマクロを、
せっかくなので、試そうと書き換えて、いろいろ試してから書く
つもりでした。file:よりも気に入っています。万々歳です。

[ ]
RE:07927 ファイル名の認識No.07932
M.D.S.-Toy さん 05/05/27 18:36
 
>誰も気付いていない気がしたので…

気づいてます。早速使ってます。いい感じです。参りました。

[ ]
RE:07929 ファイル名の認識No.07933
秀丸担当 さん 05/05/27 18:42
 

コメントありがとうございます。
意見を参考にしたいと思います。

[ ]