単語の境界となる条件のカスタマイズNo.25916
pakira さん 08/12/25 01:38
 
こんにちは。

要望になるのですが、検索や置換時の「単語の検索」とか、Ctrl + → での単語の移
動とかの「単語単位」の処理について、単語の境目となる条件を、ある程度任意にカ
スタマイズ出来ないでしょうか。

とりあえず今一番困っているのが、(最近押しつけられた仕事で)COBOLの強調表示が
遅いというもので、説明すると・・・
================
COBOL言語はハイフンを識別子に含めることが出来るので、「INPUT-DATA」などとい
う変数名を作ることができます。

現在の秀丸の仕様では、「単語の検索」を使って予約後「INPUT」や「DATA」を強調
表示させようとすると、変数名の一部分までが、予約語であると誤認識されてしまい
ます。

仕方なく、正規表現を使って「 予約語([ .\(]|$)」などと指定しているのですが、
これだと表示がかなり遅くなってしまいます。
(" "で始まる条件が大量にあるので、高速化のロジックが有効に機能していない気が
する?)
================
みたいな感じです。

もしも、「ファイルタイプがCOBOLの場合は、ハイフンは単語の境界とは見なさな
い」という指定が出来るのであれば、上記のような正規表現は使わずに、「単語の検
索」だけで強調表示の指定が出来ると思うのですが・・・


他にも Ctrl + 矢印 での単語の移動やダブルクリックでの単語の選択がスムーズに
なるとか、色々と使いやすくなる場面があると思うので、検討していただければと思
います。

p.s. ぐだぐだな文章で申し訳ないです。

[ ]
RE:25916 単語の境界となる条件のカスタマNo.25917
Iranoan さん 08/12/25 03:38
 
 pakira さん今日は、Iranoan です。
 念の為お断りしておくと、開発者とは何の関わりも無い単なる一ユーザです。
> 要望になるのですが、検索や置換時の「単語の検索」とか、Ctrl + → での単語の移
> 動とかの「単語単位」の処理について、単語の境目となる条件を、ある程度任意にカ
> スタマイズ出来ないでしょうか。
 単語の区切りについては度々要望が出ていますが、現状では出来ないですね。
私も言語毎に出来たら便利だと思います。

 ただ
> COBOL言語はハイフンを識別子に含めることが出来るので、「INPUT-DATA」などとい
> う変数名を作ることができます。
>
> 現在の秀丸の仕様では、「単語の検索」を使って予約後「INPUT」や「DATA」を強調
> 表示させようとすると、変数名の一部分までが、予約語であると誤認識されてしまい
> ます。
については、前/後方不一致を使うと速くなるかもしれません。例えば、COBOL
で識別子に使えるのが、英字とハイフンなら、予約語の定義で、
(?<![A-Za-z\-])INPUT(?![A-Za-z\-])
等と指定します。

[ ]
RE:25916 単語の境界となる条件のカスタマNo.25918
秀丸担当 さん 08/12/25 10:18
 

>要望になるのですが、検索や置換時の「単語の検索」とか、Ctrl + → での単語の移
>動とかの「単語単位」の処理について、単語の境目となる条件を、ある程度任意にカ
>スタマイズ出来ないでしょうか。

他の方からも要望があったことがありますが、いまのところできないです。
単語補完に限っては[ファイルタイプ別の設定]→[その他]→[単語補完]→[詳細
(X)...]→[さらに...]でできますが、それと似たような感じで指定できるといい
かもしれません。
あとやるとしたら、マクロの互換性は維持するべきなので、マクロでは効かない
ようにするか別のマクロ文を用意するなどが必要になってきそうです。


>仕方なく、正規表現を使って「 予約語([ .\(]|$)」などと指定しているのですが、
>これだと表示がかなり遅くなってしまいます。
>(" "で始まる条件が大量にあるので、高速化のロジックが有効に機能していない気が
>する?)

正規表現のこの指定で、体感できるほど遅くなるかどうか、少し試してみた限り
ではわかりませんでした。
もしかしたら、別のところに遅くなる原因があるのかもしれないです。

強調表示で遅くなることがあるのは、一行の文字数が何千,何万文字のとても長
い行のときに起きやすいかもしれないです。
単純に半角空白とタブ文字の強調が交互に大量にあると、それだけで遅くなるこ
ともあります。

正規表現では、.+ や .+? といった感じの指定が幾つかあって、文字列の長さが
変化するパターンを何回も試さなくてはいけないケースでは遅くなる可能性があ
ると思いますが、「([ .\(]|$)」ではそれが無いので、体感できるほど遅くなる
かどうか、試してみた限りではわかりませんでした。
Iranoanさんの提案でももしかしたら速くなるかもしれないですが。

どこが遅いか確認するためには、強調表示をいったんファイルに保存しておいて、
強調表示を減らしたり条件を変えたりすると、特定できるかもしれないです。
大量の強調表示を一括で変える場合は、一時的にhilightファイルに保存して、
そのファイルを編集すると変えやすいかもしれないです。

[ ]
RE:25918 単語の境界となる条件のカスタマNo.25929
pakira さん 08/12/26 02:16
 
>体感できるほど遅くなるかどうか、試してみた限りではわかりませんでした。

私もそれほど時間をかけて検証をしていないのですが、
「 予約語([ .\(]|$)」と「予約語([ .\(]|$)」(先頭の空白の有無が違うだけ)とで
比較した場合に、かなりの速度差を感じました。(Mobile Pentium3 1GHz, 384MB RAM)

具体的には、前者を使用して単語をダブルクリックすると、カーソルの動き(単語の
先頭に移動→単語の末尾まで選択)が目視できる程度にまで速度が低下します。(0.
5秒くらい?)
後者だと、いつも通り、単語が一瞬で選択されます。

尚、強調表示の登録には、ライブラリにある「ねぎしよしひろ」様の定義ファイルを
改造して使わせて頂いています。
強調表示の登録数が630個とかなり膨大です(汗
アウトライン解析とか、複数行コメントとかも使って、正規表現の指定も、なるべく
シンプルになるように作り替えました。

Iranoanさんご提案の前方一致については、また後日(来年になるかも)試してみま
すね。

[ ]
RE:25917 単語の境界となる条件のカスタマNo.25930
pakira さん 08/12/26 02:24
 
Iranoanさんこんにちは。

私も、前方一致が頭をよぎりましたw
ただ、前方不一致で「先頭がハイフンにマッチしない」と書くよりも、「先頭が半角
空白にマッチする」って書く方が何となく速そうな気がしたので、ボツ案としてしま
っていました。

というわけで、今度時間のあるときに、前方不一致を試してみたいと思います。

[ ]
RE:25929 単語の境界となる条件のカスタマNo.25933
秀丸担当 さん 08/12/26 10:23
 

ねぎしよしひろ様の強調表示定義ファイルを使ってやってみたところ、確かに体
感できるくらいに遅くなる場合があることが確認できました。
630個もあると、処理が積もって遅くなってしまうようです。
先頭に空白が無い場合は、確かに少し速いようです。
Iranoanさんご提案の前方不一致の方法でも少し速いようです。前方不一致であ
れば問題もなく、少し速くすることができそうです。

正規表現を使わず、単語の検索だけだと、かなり速くなりました。
ご指摘の通り、単語の判断を変えることができると、一番高速にできると思いま
す。
できるかどうかわかりませんが、そういうことができたらいいということで今後
のネタとして参考にさせていただきます。

[ ]
RE:25933 単語の境界となる条件のカスタマNo.25939
pakira さん 08/12/26 21:55
 
わざわざご検証していただけたのですね。お手数をおかけしました。

>Iranoanさんご提案の前方不一致の方法でも少し速いようです。前方不一致であ
>れば問題もなく、少し速くすることができそうです。

なるほど、前方不一致を使うと若干速くなるのですね。
早速、年明けにでも試してみることにします。

ありがとうございました!

[ ]