Grepはもっと早くならないか - 秀丸エディタ関連ソフト会議室 - スレッド20406, 2005/11/15

Grepはもっと早くならないか

なむnomoto さん　05/11/15 22:39

　秀丸担当さん
　　　　　　　　　　　　　　　　　　　　　　なむnomotoです
　秀丸に満足はしているんですが、
　Grepを使うマクロで、２０Mほどのデータを検索すると
　時間がかかりますので、
　もう少し早くする方法はないモノかと、お尋ねします。

　４００Mbyteを単なるGrepしても、結構な時間がかかります。

　ハードディスクが大容量になったので、ついつい、欲張ってしまいます。
　
　何かご存じならば教えて下さいませ。

RE:20406 Grepはもっと早くならないか

ENCODINGSHIFTJIS さん　05/11/16 00:37

本格的に全文検索タイプ(事前にインデックスを作成)のソフト
を使用しないと無理です。

http://www.forest.impress.co.jp/article/2003/07/15/satori.html
とか
○○デスクトップ検索
とか
ただ、インデックスが適合した形でできるか？はわかりません。

RE:20407 Grepはもっと早くならないか

ENCODINGSHIFTJIS さん　05/11/16 00:48

ディスクのデフラグをかけて断片化を緩和すると、気持ち早くなるかも。
Windows のデフラグで不満なら、１ヶ月試用版を探してみましょう

デフラグはバックアップ-リストアを慎重に計画しても可能です。

RE:20408 Grepはもっと早くならないか

秀丸担当 さん　05/11/16 10:58

>　Grepを使うマクロで、２０Mほどのデータを検索すると
>　時間がかかりますので、
>　もう少し早くする方法はないモノかと、お尋ねします。

秀丸エディタの機能ではありませんが、ENCODINGSHIFTJISさんの言われているよ
うなインデックスを作成して全文検索するものがあると高速にできるかもしれな
いです。
ただ、正規表現を使ったりといった、grepと同じような使い方はできないかもし
れません。

grepの実行ダイアログで、エンコードの種類を自動判定ではなく固定にしておく
と、多少ですが速度が上がると思います。
エンコードの種類を指定してgrepする場合、[その他]→[動作環境]→[検索]→
[ダイアログボックス]→[grepのダイアログボックス]を新タイプにしておく必要
があります。

RE:20408 Grepはもっと早くならないか

なむnomoto さん　05/11/16 14:38

コメントありがとうございます。
　　　　　　　　　　　　　　　　　　　　　　なむnomotoです
　んではサトリとやらをやって見ようと、探しましたが、
　サトリ作者のページに行き当たりませんでした。
　　　　　　　　　　　　　　　　　ページが削除されている感じですが・・・。
　　んで、正規表現や新旧漢字同一視あいまい検索などが使えないと、逆に不自由で
す。

>ディスクのデフラグをかけて断片化を緩和すると、気持ち早くなるかも。
>Windows のデフラグで不満なら、１ヶ月試用版を探してみましょう
>
>デフラグはバックアップ-リストアを慎重に計画しても可能です。

　　デフラグというような問題じゃなくて、プログラム実行で、別の高速検索プログ
ラムなどを使えるんじゃあないかと、
　　密かに期待したところです。
　　　１０倍は早くなるとかです。(^^;)　　ダメですか、はぁ～・・・

RE:20410 Grepはもっと早くならないか

なむnomoto さん　05/11/16 14:46

　　　　　　　　　　　　　　　　　　　　　　　　　なむnomotoです
>秀丸エディタの機能ではありませんが、ENCODINGSHIFTJISさんの言われているよ
>うなインデックスを作成して全文検索するものがあると高速にできるかもしれな
>いです。
>ただ、正規表現を使ったりといった、grepと同じような使い方はできないかもし
>れません。

　　何か高速検索ができる外部プログラムを経由するとか、秀丸に高速アクセルを装
着すると
　　１０倍速になるとか、あれば良いのですが、無理なら秀丸担当さんに押してもら
うとか、
　　そんな訳には行かないですが、何か対策して欲しいという要望です。

>grepの実行ダイアログで、エンコードの種類を自動判定ではなく固定にしておく
>と、多少ですが速度が上がると思います。
>エンコードの種類を指定してgrepする場合、[その他]→[動作環境]→[検索]→
>[ダイアログボックス]→[grepのダイアログボックス]を新タイプにしておく必要
>があります。

　　おおこれは耳寄り情報です。
　　これは検索grepマクロの中でセットするフラグのようなコマンドはあるのですか？
　　マクロでは無理ですか？

RE:20416 Grepはもっと早くならないか

秀丸担当 さん　05/11/16 16:26

>　　何か高速検索ができる外部プログラムを経由するとか、秀丸に高速アクセルを装
>着すると
>　　１０倍速になるとか、あれば良いのですが、無理なら秀丸担当さんに押してもら
>うとか、
>　　そんな訳には行かないですが、何か対策して欲しいという要望です。

正規表現などが伴わなければ、秀丸エディタでもインデックスを作成した全文検
索を装備するという可能性も考えられますが、正規表現などが伴って１０倍速と
いうのは難しいです。

>　　これは検索grepマクロの中でセットするフラグのようなコマンドはあるのです
>か？
>　　マクロでは無理ですか？

マクロではエンコードの種類の指定は現在のところできていません。
できるように検討したいと思います。

RE:20415 Grepはもっと早くならないか

ENCODINGSHIFTJIS さん　05/11/16 17:17

それでは、ハードウェアの力を借りる形になります。
キーになる検索用語は
半導体ディスク　【シリコンディスク】
頭使わず金使う、ですが、確実です。
機器組込み用（それほど速くはない）と
大規模DB用（早い、やや高価）

PCのメモリスロットに空きがあるなら、メモリ増設して
RAMDISK に設定する手があるでしょう。
システム起動毎に初期格納になりますが

RE:20419 Grepはもっと早くならないか

なむnomoto さん　05/11/16 19:40

　　　　　　なむnomotoです

>正規表現などが伴わなければ、秀丸エディタでもインデックスを作成した全文検
>索を装備するという可能性も考えられますが、正規表現などが伴って１０倍速と
>いうのは難しいです。

　　逆に言えば、「正規表現やあいまい検索を使わなければ、１０倍速も
　　装備できます」というようにも聞こえまする　が・・・・はかないかな？

>マクロではエンコードの種類の指定は現在のところできていません。
>できるように検討したいと思います。

　　嬉しい朗報！　私はShift-jis専用です。GBもBIG5もSift-jisに変換して行います。
　　　　ですから、Shift-jis専用だけでも良いです。

　　第一、GBコードの漢字をどうやってGrep検索窓に打ち込むのでしょうか、
　　これは中国語の辞書が必要で、中国語のPinInが正確でないと検索語に
　　できません。
　　BIG5コードも同じです。韓国語の漢字も同じ。
　　Sjisで漢字を打ち込まなければならない者には、ただ「見るだけよ」のデータな
んです。
　　気に入って買っても使えません（贋作物とは違うけど）。

ユニコードの漢字は、
　　Sjisで作成後、コード変換すればできるでしょうが、検索データとして
　　使うには、利用者はユニコード用のIME辞書が必要でしょう。
　　　　　おそらく、メールなど読むだけのための利用度で優先して話が行き交って
いるような感じ。
　　実際には使われてないのじゃないかな？　存在するんでしょうか？
日本語で打ち込んだら、Sjisじゃなくて、ユニコードの文字になる辞書。
　　　・・・・ご存じの方教えて下さい。

　　マクロにはSjis専用フラグだけでも、お願いしたい所です。

　　因みに、Shift-jisに限定しておいてマクロを実行すると、「自動認識」よりは、
１０％早くなりました。
　　つまり８０秒かかったgrep検索が、７２秒くらいになったからです。
マクロに設定がないので、これは既設定が生きているからですか？

　　それとも何かの間違い？・・・ワテの勘違いなんだろうか(^^;)

　　

RE:20422 Grepはもっと早くならないか

なむnomoto さん　05/11/16 20:02

ENCODINGSHIFTJISさん
　　　　　　　　　　　　　　　　　　なむnomotoです

　お名前のように、私はShift-jisしか検索には使いません。
　Big5やGBデータを使いますが、それは読むためだけです。
　ですから、「Shift-jisに変換せよ」見たいなお名前は、頼もしいなあ～

>それでは、ハードウェアの力を借りる形になります。
>キーになる検索用語は
>半導体ディスク　【シリコンディスク】
>頭使わず金使う、ですが、確実です。

　　う、う、頭も金もなく、愚痴だけのヤツは中古品をあさるか(^^;)
　　　どれくらいかかるんですか？・・・・と小銭入れを探すなって。

>機器組込み用（それほど速くはない）と
>大規模DB用（早い、やや高価）
>
>PCのメモリスロットに空きがあるなら、メモリ増設して
>RAMDISK に設定する手があるでしょう。
>システム起動毎に初期格納になりますが

　　ふうむ。高そう。実は、秀丸エディタが使えないと結局不自由するので、
　　一般利用者も、私と同様に使える事が原則なんです。
　　　　　　　　　原則なら先に云わねばいけませんけど。
　　手元にあるマシン。1.5GHz　と　1GHz を同じ検索で比較すると、
　　　　　　　　　　１分１５秒　と　３分３２秒で結果が出ました。
　　メモリ量などの違いもあるでしょうけど、これだと、３GHｚマシンを拾って来た
方が
　　安くて、便利かも　と思ったりします。（落ちてないワな～）。
　　メモリ増設は高価な効果が出るかも知れませんね。

　　ともかく、秀丸の高速Grep装着に期待するところ大なんです。
　　今のところ頻繁使用は、総量４２３MBの4,000ファイルですから、これを
　　誰でも簡単にしかも高速に検索できたらなあ　と企んでいるんです。

　　ENCODINGSHIFTJISさんが、ご興味をお持ちなら、CDに焼いてお送りします（全漢
文データ）。
　　メールじゃあ迷惑でしょうし。　中身はENCODING SHIFT-JISにしています。(^^;)

RE:20424 Grepはもっと早くならないか

なむnomoto さん　05/11/16 21:36

　　　　　　　　　　　　　　　　　　なむnomotoです
見つけました。３Ghzマシン。
　ところがこいつは、grepでのろのろと動き、1.5GHzマシンは１分３０秒で終わるの
に、
　なんと７分もかかります。

　秀丸か何かの設定で早くなるんでしょうか？
　お分かりでしたら、教えて下さいませ。
　　　・・・・・やっぱり金使うしかないのかなぁ
＿＿＿＿

RE:20425 Grepはもっと早くならないか

なむnomoto さん　05/11/16 22:00

　　　　　　　　　　　　　　　　　　なむnomotoです
> 見つけました。３Ghzマシン。
>　ところがこいつは、grepでのろのろと動き、1.5GHzマシンは１分３０秒で終わる
>のに、
>　なんと７分もかかります。

理由はわかりませんが、早い秀丸の設定をregをコピーして読み込ませ、
　　ディスクをクリーンして、インターネットのファイルも削除して、
　　実行したら、なんと、３８秒です。
　　　　　　　　　ううむこれだけ早ければ、良いです。
　　1.5Ghzだと、なぜか今度は、１分１２秒
　　3Ghzだと、　　　　　　　　　３８秒です。
　　　　　　　　　　　１.８９倍でしょうか。約２倍のスピードです。
　　　　　・・・・・３Ghzマシンを拾って来なくては。
＿＿＿＿

RE:20406 Grepはもっと早くならないか

nohhoso さん　05/11/16 23:35

なむnomoto さん

nohhosoです。
こんなものを作ってます。よかったら試してみてください。
正規表現は使えませんが・・・。

DesktopHE
http://freemind.s57.xrea.com/desktophe/index.html

RE:20423 Grepはもっと早くならないか

秀丸担当 さん　05/11/17 10:13

>　　逆に言えば、「正規表現やあいまい検索を使わなければ、１０倍速も
>　　装備できます」というようにも聞こえまする　が・・・・はかないかな？

今までのgrepとは全く異なるもの新しく作れば、その可能性があるということで、
正規表現を使わなければ即座に１０倍速にできるるというわけではないです。
使いかってもインデックスを作成する過程が生まれるので、grepとは異なるもの
になるとと思います。
もしやるとすれば、秀丸エディタというより新しい別個のソフトを作る感じにな
ってしまうと思います。

>　　第一、GBコードの漢字をどうやってGrep検索窓に打ち込むのでしょうか、
>　　これは中国語の辞書が必要で、中国語のPinInが正確でないと検索語に
>　　できません。

確かにその通りでして、grepでの検索文字列の入力は日本語しか対応できていな
いため、GBコードなどのgrepは選択しても意味が無い状態になってしまっていま
す。対策を検討したいと思います。

>　　因みに、Shift-jisに限定しておいてマクロを実行すると、「自動認識」よりは、
>１０％早くなりました。
>　　つまり８０秒かかったgrep検索が、７２秒くらいになったからです。
> マクロに設定がないので、これは既設定が生きているからですか？

マクロの場合は常に自動認識となるので、２回目はディスクキャッシュが働くな
どによって高速になったのではないかと思われますが、どうでしょう。

RE:20423 漢字とSift-jis

鳩２さん　05/11/17 13:22

鳩です。こんにちは。どうもお久しぶりです。

》嬉しい朗報！　私はShift-jis専用です。GBもBIG5もSift-jisに変換して行います。

　これってどのようにされるのでしょうか。
　文字数増加とSift-jisというと単純に「JIS X 0213:2000」しか思い浮かびません
が、これにあわせてコード変換されているのでしょうか。

　さらに、以前から漢字で一番シビアなのはなむnomotoさんのような経典の研究者で
はないかと思っていたのですが、そもそも経典の使用文字数はSift-jisで扱える程度
なのでしょうか。

　普通に考えても、たとえば康煕字典は約５万文字、これに入らないような西夏文字
の経典などもありそう（？）ですから、Sift-jisで経典を扱うというのが不思議のよ
うに思えます。

94X94X2面　17,672字
Sift-jis最大　11,280字
X 0213　11,233字
（http://internet.watch.impress.co.jp/www/column/ogata/part2_2.htm）
でどうやっても何万という文字にはとてもたりません。

　横からあんまり関係ない話をしてどうもすみません。が、以前から機会があったら
おたずねしたいと思っていました。

　「先月、慶州・海印寺の八万大蔵経経板を見てきた」鳩
　　　　　　　　　　　　　（仏教関係者ではありません）

RE:20426 Grepはもっと早くならないか

なむnomoto さん　05/11/17 13:51

　　　　　　　　　　　　　　　　　　なむnomotoです
たびたび、自問自答。

>> 見つけました。３Ghzマシン。
>>　ところがこいつは、grepでのろのろと動き、1.5GHzマシンは１分３０秒で終わる
>のに、
>>　なんと７分もかかります。

　　理由が分かりました。
　　アンチウイルスが邪魔していました。
　　TXTなどは良いのですが、appは怪しがって検査してます。
　　それで、極端に遅くなっていました。
　　一旦アンチウイルス監視を解除すると、俄然早くなります。

RE:20430 Grepはもっと早くならないか

なむnomoto さん　05/11/17 16:12

秀丸担当さん
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　なむnomotoです

>今までのgrepとは全く異なるもの新しく作れば、その可能性があるということで、
>正規表現を使わなければ即座に１０倍速にできるるというわけではないです。
>使いかってもインデックスを作成する過程が生まれるので、grepとは異なるもの
>になるとと思います。
>もしやるとすれば、秀丸エディタというより新しい別個のソフトを作る感じにな
>ってしまうと思います。

　　超高速のGrep検索が可能なら嬉しいですが、興味はありますので、
　　期待しています。私だけでもないでしょう。
　　本当のエディターだから、高速検索機能も付いている、というような
　　時代が来るような気もします。宜しくお願いします。

　　人文科学系の学生も、ワープロソフトとゲームとインターネットだけだった時代
から、
　　いまや、エディターを使って当たり前になっています。
　　Grep検索が使えないと、仲間になれないからですね。エディターの検索高機能は、
期待されるものです。

>確かにその通りでして、grepでの検索文字列の入力は日本語しか対応できていな
>いため、GBコードなどのgrepは選択しても意味が無い状態になってしまっていま
>す。対策を検討したいと思います。

　　是非とも宜しくお願い致します。検索の高速化対策。
　　その場合に、ヘルプにgrepがやたら遅い場合の対策をいくつか書いてあると、万
人が喜びます(^^;)
　　１．アンチウイルスの監視を一時的に止めると高速になる場合があります。検索
が終わったらアンチウイルス監視を機能させて下さい。
　　２．お使いのコンピュータの空きエリアが極端に少ないと、遅くなる場合があり
ます。ディスククリーンやゴミ箱を空にするなどを行って下さい。
　　・・・・・など、他にも宜しくお願い致します。

>>　　因みに、Shift-jisに限定しておいてマクロを実行すると、「自動認識」よりは、
>>１０％早くなりました。
>>　　つまり８０秒かかったgrep検索が、７２秒くらいになったからです。
>> マクロに設定がないので、これは既設定が生きているからですか？
>
>マクロの場合は常に自動認識となるので、２回目はディスクキャッシュが働くな
>どによって高速になったのではないかと思われますが、どうでしょう。

　　え！「マクロの場合は常に自動認識となるので」すか　(+_+)
　　多分、ディスクキャッシュが効果を出したんでしょうね。
　　ならば、ぜひ　文字コードのSjisコマンドを是非とも宜しくお願い致します。

　　/fs はSHIFT-JIS　のフラグと書かれています。
　　もしそうであるなら、　hidemaru.exe /x kkkk.mac /fs　と、
ショートカットマクロアイコンに記入するとShift-jis限定で検索が
　　行われるのでしょうか？　これだと早くなるんですか？
＿＿＿＿＿＿＿

RE:20431 漢字とSift-jis

なむnomoto さん　05/11/17 17:20

　鳩さん、
　　　　　　　　こんにちは、　　　なむnomotoです

>》嬉しい朗報！　私はShift-jis専用です。GBもBIG5もSift-jisに変換して行います。
>
>　これってどのようにされるのでしょうか。
>　文字数増加とSift-jisというと単純に「JIS X 0213:2000」しか思い浮かびません
>が、これにあわせてコード変換されているのでしょうか。

　　第３水準漢字は使いません。制作・変換の文字はjis1/ji2 のみです。
　　ご存じのように、もちろん印刷されている漢字や文字が全てデータにはできませ
ん。
　　したくても、jisの壁があってできないのです。
　　この壁は、日本全国の一般的なマシンが持っていますから、私が解決することは
できません。

　　　鳩さんにもできません。多分。　　将来もできないでしょう。当分。

　　jis1/jis2 に限って行うならば漢文はデータにできます。しかも誰でも使える。
　　つまりjis外文字(0.3%)に拘って、残りの99.7%の漢文データの検索を諦めるのは、
愚かに思えます。
　　　　漢文データにして文字が表示・検索できない％は、私の所では★ですが、
　　　　これは0.3%（通常の仏教書漢文）～３％（密教梵字書籍など）です。

>　さらに、以前から漢字で一番シビアなのはなむnomotoさんのような経典の研究者で
>はないかと思っていたのですが、そもそも経典の使用文字数はSift-jisで扱える程度
>なのでしょうか。

　　現在のコンピュータで、印刷物や写本の漢文や日本文を、すべてそっくりに写真
ではない、文字データにすることは不可能です。
　　可能だとしても、印刷物よりも何倍もの費用がかかります。つまり実用性が無い
データになるでしょう。
　　だからといって、便利なマシンの持つ機能を使わない手はありません。私は使い
ます。使えるだけ使います。

>　普通に考えても、たとえば康煕字典は約５万文字、これに入らないような西夏文字
　　　　　：：：：：（省略）
>でどうやっても何万という文字にはとてもたりません。

　　それは、写本經典や印刷經典・佛典のことを云われているようです。
　　コンピュータデータと印刷物や写本とが一致するものとの、期待過剰が生んだ認
識だと思います。
　　　　あるいは、期待過剰が生んだ、見たこともないデータのことを云われている
ようです。

　　私は、印刷物・写本とコンピュータデータとは全く別物だと考えています。
　　中国古典・佛教文献・歴史文献の印刷物は必ず必要です。
　　　　　戸籍なども、この頃は全国ネットでデータが完成しているようですが、紙
に書いた届けは、
　　　　　県庁地下倉庫に厳重保管されています。
　　ですから、研究で文献証拠にデータを提示することは、私には違反行為です。
　　コンピュータデータは改竄可能・保存性も脆弱・無くなりやすいものです。
　　とうてい印刷物・写本の保存性や証拠能力に及ばないと思います。

　　といいつつ、私は写本から佛教の漢文書籍を編纂印刷刊行しています。これは妥
協がありません。相当に厳密です。
　　方や便利な漢文データも作成しています。便利な索引として使えるからです。検
索などのように別の使い方があるからです。
　　つまり、使い分けです。

　　梵字・送りがな・返り点・異体字・別体字・オコト点などにも大切な文化があり
ます。
　　これらは、jis漢文データでは無理です。BIG5でGBでも無理。ユニコードでも無理。
　　XMLなどにすれば再現性は不可能では無いでしょうが、印刷物を見る方が早いし、
保存性に優れています。
　　データの携帯性には、印刷物はおとるでしょうけど。

　　ですから、ユニコードの時代だと云われても、誰がどこで正しく理解しているの
か分からないのに、
　　ユニコードの漢字を検索窓に打ち込める辞書も無いのに、ユニコードデータにな
ると未来があるように思うのは、
　　ある意味では誤解に等しいです。電子メールなどの表示には有効でしょう。
　　印刷物や写本と、漢文データは全く別物でなければならないと思います。
　　　基になる印刷物・写本がないと、漢文データはできませんけど。

　　ですから、「秀丸」エディタ検索機能には期待しているんです。期待過剰くらい
があるいは
　　ちょうど良いこともあるんで、秀丸担当さんには頑張って頂きたいです。
　　Shift-jis漢文でできるだけ迫りたいと言うのが、私の姿勢なんです。

>　横からあんまり関係ない話をしてどうもすみません。が、以前から機会があったら
>おたずねしたいと思っていました。

　　私も、ご覧になっている皆さんや関心の在る方々に、一度は説明したいと思って
いた事です。
　　説明しなくても、実際に便利に使われていれば、それで良いのですけど。
　　明白にしておく利点もあるかも知れません。そういう意味では、嬉しいコメント
です。ありがとうございます。

RE:20429 Grepはもっと早くならないか

なむnomoto さん　05/11/17 17:48

nohhosoさん
　　　　　　　　　はじめまして　なむnomotoです

>こんなものを作ってます。よかったら試してみてください。
>正規表現は使えませんが・・・。
>
>DesktopHE
>http://freemind.s57.xrea.com/desktophe/index.html
>

　　おお、昨日のバージョンアップがアップされていますね。

　　「正規表現は使えない」とありますが、
　　改行は無視する　……　はありますか？
　　P:123c とか L:99 ……　を飛び越えて連続させて検索することはできますか？

　　TXKとかappとかの拡張子ファイル（中は単なるテキストデータ）は、
　　検索できますか？

　　私の目的はハイパーテキストじゃないから、何だか大げさですが、使ってみよう
かな？

RE:20435 Grepはもっと早くならないか

nohhoso さん　05/11/18 00:01

>　　　　　　　　　はじめまして　なむnomotoです

ご挨拶が遅れました。はじめまして、nohhosoと申します。

>　　「正規表現は使えない」とありますが、
>　　改行は無視する　……　はありますか？
>　　P:123c とか L:99 ……　を飛び越えて連続させて検索することはできますか？

改行は無視されるようです。
ようです、というのは、DesktopHEのページで書いているとおり、
実際に検索を行っているのはHyper Estraierという独立した
検索ツールだからです。

「P:123c とか L:99」というのは、何か特殊な文字なのでしょうか。
正規表現ができませんので、OR検索をするしかないと思います。
現在のバージョンのDesktopHEはOR検索を使えませんが、
Hyper EstraierはOR検索をサポートしているので、
次のバージョンで使えるようにしようと思います。

>　　TXKとかappとかの拡張子ファイル（中は単なるテキストデータ）は、
>　　検索できますか？

テキストファイルとしてインデックスする拡張子を追加することはできます。

>　　私の目的はハイパーテキストじゃないから、何だか大げさですが、使ってみよ
>うかな？

あるいは、Hyper Estraierを秀丸マクロから使う方法もあると思います。

Hyper Estraier
http://hyperestraier.sourceforge.net/

上記のページからWindows用のバイナリをダウンロードし、コマンドラインか
DesktopHEでインデックスを作成します。
あとは、次のようなマクロを登録しておけば、Hyper Estraierでの検索が
秀丸エディタから行えます。

----------------------------------------------------------------
// Hyper Estraierで検索するマクロ

// estcmd.exe の絶対パス。スペースが含まれる場合は、両端に \" を付ける必要が
あります
$estcmd = "C:\\devtools\\hyperestraier-1.0.5-win32\\estcmd.exe";

// インデックスの絶対パス。スペースが含まれる場合は、両端に \" を付ける必要
があります
$index = "\"C:\\Documents and Settings\\username\\Application Data\\DesktopH
E\\index\"";

// 一時出力ファイルの絶対パス。スペースが含まれる場合は、両端に \" を付ける
必要があります
$tempfile = "C:\\temp\\temp.txt";

$searchstr = input("検索文字列を入力してください。");
if (strlen( $searchstr ) == 0) endmacro;

run $estcmd + " search -ic CP932 -vh -sf -max -1 " + $index + " " + $searchs
tr + " > " + $tempfile;

openfile $tempfile, utf8;

----------------------------------------------------------------

ただ、結果がgrepの書式とは異なるので、タグジャンプはできません。
何かいい方法はないかと考えているところです。(^_^;

RE:20423 Grepはもっと早くならないか

Kamonohasi さん　05/11/18 00:43

こんばんは、カモノハシと申します。
横からこんな所にだけコメントするのもなんですが……
>　　使うには、利用者はユニコード用のIME辞書が必要でしょう。
>　　　　　おそらく、メールなど読むだけのための利用度で優先して話が行き交っ
>ているような感じ。
>　　実際には使われてないのじゃないかな？　存在するんでしょうか？
> 日本語で打ち込んだら、Sjisじゃなくて、ユニコードの文字になる辞書。
>　　　・・・・ご存じの方教えて下さい。
いったいどんなIMEをお探しなんでしょうか。
Unicode文字列の辞書登録が出来るってことでしょうか？
どんなソフトにも強制的にUnicodeで文字を送り返すIME？
(そんなものに意味があるか分からないので前者だとは思いますが……)
MS-IMEは使わないので普通なのかも知れませんが、ATOK 2005 は基本的にUTF-16で
データを扱っているように感じられます。
辞書登録にも、変換候補にもUnicodeにしかない漢字がでます。いつのころからかよ
うになってます。

RE:20433 Grepはもっと早くならないか

秀丸担当 さん　05/11/18 10:08

>　　/fs はSHIFT-JIS　のフラグと書かれています。
>　　もしそうであるなら、　hidemaru.exe /x kkkk.mac /fs　と、
> ショートカットマクロアイコンに記入するとShift-jis限定で検索が
>　　行われるのでしょうか？　これだと早くなるんですか？

このようにしても、grep文でsjisに限定されるようにはならないです。
やはり、grep文にパラメタを追加するしか方法は無いです。
いろいろ修正点が出てくるので、grep文にパラメタを追加したV5.11βを出そう
と思います。

RE:20439 Grepはもっと早くならないか

なむnomoto さん　05/11/18 10:56

　秀丸担当さま
　　　　　　　　　　　　　　　　　　　　　　なむnomotoです

>>　　/fs はSHIFT-JIS　のフラグと書かれています。
>>　　もしそうであるなら、　hidemaru.exe /x kkkk.mac /fs　と、
>> ショートカットマクロアイコンに記入するとShift-jis限定で検索が
>>　　行われるのでしょうか？　これだと早くなるんですか？
>
>このようにしても、grep文でsjisに限定されるようにはならないです。
>やはり、grep文にパラメタを追加するしか方法は無いです。
>いろいろ修正点が出てくるので、grep文にパラメタを追加したV5.11βを出そう
>と思います。

　　おおおお！　すばやい対応有り難うございます。
　　宜しくお願い致します。

RE:20437 Grepはもっと早くならないか

なむnomoto さん　05/11/18 11:06

カモノハシさん
　　　　　　　　　　　　こんにちは　　なむnomotoです

>いったいどんなIMEをお探しなんでしょうか。
>Unicode文字列の辞書登録が出来るってことでしょうか？
>どんなソフトにも強制的にUnicodeで文字を送り返すIME？
>(そんなものに意味があるか分からないので前者だとは思いますが……)

　　ユニコードの漢文データを秀丸で検索するには、ユニコード漢字が打ちこめないと
　　検索できないことになるはず、という意味なのです。
　　分かりにくい書き方で済みません。

>MS-IMEは使わないので普通なのかも知れませんが、ATOK 2005 は基本的にUTF-16で
>データを扱っているように感じられます。
>辞書登録にも、変換候補にもUnicodeにしかない漢字がでます。いつのころからかよ
>うになってます。

　　ということは、秀丸がユニコードの漢文を表示していて、
　　（ユニコードのデータを持っていないので実験できませんが、）
　　ATOK 最新版で、秀丸のGrep検索窓に検索語句を記入すると、正しく
　　検索してくれるのでしょうか？　それは現在はできないのじゃないか、という
　　意味なんです。
　　ですから、表示ができるかどうかという事以上に、一般的にGrep検索ができる必
要があるので、
　　Shift-jis 以外の文字コードではなかなか困難じゃないかという意味です。

RE:20436 Grepはもっと早くならないか

なむnomoto さん　05/11/18 11:37

　nohhosoさん
　　　　　　　　　　　　　　　　　なむnomotoです
　詳しいマクロを有り難うございます。

　desktopHE を２台のマシンで、別々に実行してみました。
　インデックス作成後に、再度最適化を実行しないと動きませんでした。

　インデックス作成を　４００MBデータに行いました、一晩かかりました。
　なんと、インデックスは元の３倍ほどになったようです。

　んで、検索。
　　いくつかの検出ファイル名が表示されましたので、ファイルをクリック。
　　最初の検出ファイルの内容表示で、HEが死んでしまいました。
　　再起動後、他のファイルでは内容が表示されました。

　　問題は、検出語句が一体どこにあるのかが分かりづらいです。
　　１メガファイルの”どこかに”あることは分かりますが、何頁の何行目なの？
　　という要求には応えられていませんね。<==これは私には重要な部分です。
　　　行数が分かっていれば、本文へジャンプできますが、これも出来ないので、文
献データ検索にはまだ利用できないですね。
　　漢字の新旧同一視ができていない見たいですね。
　　（正規表現検索不可に含まれた事項なのかも知れませんが。）

　　私の方には、インデックス化できた漢文データも準備してこれをGrep検索します。
　　このGrep検索スピードを上げることはできないか、というところが今の要求ポイ
ントです。
　　　現在の状態では、desktopHE を使い検索するより、秀丸のGrep検索の方が、利
用には早いですし、正確です。
　　　タグジャンプで本文表示もできますし、
　　　正規表現も使えます。
　　　新旧漢字問題もクリアできています。

>テキストファイルとしてインデックスする拡張子を追加することはできます。

　　出来るようでしたので、これで、インデックスを作成しました。

>あるいは、Hyper Estraierを秀丸マクロから使う方法もあると思います。

　　なるほど、これは今後の開拓部分のように思います。

>// Hyper Estraierで検索するマクロ

　　私のような文献データ検索には、秀丸Grepマクロ検索の方が、今のところは
　　便利のようです。

>ただ、結果がgrepの書式とは異なるので、タグジャンプはできません。
>何かいい方法はないかと考えているところです。(^_^;

　　一般的な日本文検索でも、タグジャンプは必要だと思いますので、
　　ぜひ装備された方が良いように思います。

＿＿＿＿＿

RE:20432 Grepはもっと早くならないか

ENCODINGSHIFTJIS さん　05/11/18 14:15

そのほか、秀丸マクロ高速化としては
画面（更新）表示せず実行とか、画面を表示すると毎秒千行は処理できないと思いま
す。

本格的に
古典文学・漢籍関連の全文検索ソフトを探すのを奨めます。
台湾・中国にもソフトはあります。

------------ 希望の無い話 ------------

線状のデータの検索で最先端なのは「遺伝子・塩基配列」の解析です。
検索ソフトは研究者を投入してます、専用ハードも作っています。金額が違うので、
経典には使えません。

・プロセッサ・フォーラムのネタの受け売り
FREE LUNCH IS OVER
で検索すると

ここでAdam Lake氏が引用したのは「The Free Lunch Is Over:A Fundamental Turn T
oward
Concurrency in Software」(by Herb ...
これを「Free Lunch」(タダ飯)とするならば、
マルチコア時代は「Free Lunch is Over」(タダ飯時代の終焉)というわけだ。

特にこの基調講演は、Free Lunch is over:つまりどんなプログラムを書いても、CPUの
性能アップにより高速に動作するという時代は終ったという ... 2005に寄稿された"The
Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software"である。

が出ます。

PCはこれから少し待っても１０倍速に、なかなか「なりません」。
VB でトロいプログラマの言い訳
「CPUがムーアの法則」で速くなるから大丈夫、とはいかない。

しかも、マルチコアを無駄なく使うノウハウや構築の方法論は
見通しが暗い。UML、構築フレームワーク、合成など、スジ書きの
単語は幾つもあるのですが（未実現）。
第一、単プロセッサの最適化すら簡単にはできないと言うのに。

今は、ハード/ソフトとも人海戦術でマルチプロセッサに対応している
次の開発時に前回のノウハウは使えない。

高校卒業時には単プロセッサは修了していて、大学に入ったら
マルチプロセッサを勉強するぐらいの勢いじゃないと
マルチプロセッサを無駄なく使いこなせないかも、と言う人もいます。

GCCを使う人なら、分散コンパイルの勉強するといいかも、しれません。

RE:20441 Grepはもっと早くならないか

クラフト さん　05/11/18 16:32

>>MS-IMEは使わないので普通なのかも知れませんが、ATOK 2005 は基本的にUTF-16で
>データを扱っているように感じられます。
>>辞書登録にも、変換候補にもUnicodeにしかない漢字がでます。いつのころからか
>ようになってます。
>
>　　ということは、秀丸がユニコードの漢文を表示していて、
>　　（ユニコードのデータを持っていないので実験できませんが、）
>　　ATOK 最新版で、秀丸のGrep検索窓に検索語句を記入すると、正しく
>　　検索してくれるのでしょうか？　それは現在はできないのじゃないか、という
>　　意味なんです。

これについてテストしてみました。
環境：WindowsXPProfessional、秀丸V5.10

秀丸で文字コードをUnicodeにして保存して、開いたテキストファイルに、(ATOKパレ
ットから)Unicodeにしかない文字「サンズイ」に「井」を入力して、この文字を秀丸
の検索ダイアログから検索したところ、検索されました。

ハングル文字とかも問題なく検索できるみたいです。
ハングルの場合、フォントセットがGulimでないと全く読めない文字になりますが。

RE:20440 Grepはもっと早くならないか

秀丸担当 さん　05/11/18 18:16

V5.11β1を作成してみましたので、もしよろしければ確認ください。
もし何かあればβ版会議室に報告を頂けるとありがたいです。

以下のページに一番下の部分からダウンロードできます。
http://hide.maruo.co.jp/software/hidemaru.html

RE:20446 Grepはもっと早くならないか

なむnomoto さん　05/11/18 19:15

　秀丸担当さん
　　　　　　　　　　　　　　　　　　　　なむnomotoです

　すばやい対応アップですね。有り難うございます。

　ショートカットマクロアイコンでGrepマクロを実行しますので、
　助かります。

RE:20445 Grepはもっと早くならないか

なむnomoto さん　05/11/18 19:42

　クラフトさん
　　　　　　　　こんばんは　　　なむnomotoです

>これについてテストしてみました。
>環境：WindowsXPProfessional、秀丸V5.10

　　有り難うございます。その気がない私に代わって有り難うございます。

>秀丸で文字コードをUnicodeにして保存して、開いたテキストファイルに、
>(ATOKパレットから)Unicodeにしかない文字「サンズイ」に「井」を入力して、
>この文字を秀丸の検索ダイアログから検索したところ、検索されました。

　　Atok辞書がユニコード文字なのか、jis+ユニコードなのかハッキリさせないとい
けない事態ですね。
　　それとも、Atok は、文字入力して確定した文字を、ユニコードかSjisか判定し
て、検索データとして送り出すんでしょうか？

　　その検索語を、前後文字のある語句にして、Grepしても大丈夫なんでしょうか？
　jis+ユニコード+jis　の語句。

　　検索ＯＫだと。改行コードも、検索マクロが対応しないといけないですね。「改
行を無視する」のは大丈夫でしょうか？

　　実験して見れば分かるんですね。

　　新旧漢字同一視のあいまい検索データhmjre.txtも、ユニコード対応にしないと
　　いけないのかと・・・・心配(^^;)
　　あいまい検索データhmjre.txtに、ユニコードとの対照関係を記入しておけば、
使えるのかな？

>ハングル文字とかも問題なく検索できるみたいです。
>ハングルの場合、フォントセットがGulimでないと全く読めない文字になりますが。

　　中国語GBでもBIG5でも、データ表示されている画面から、文字をコピーして拾っ
た語句は、そのコード文字だと思いますが、
　　IMEの方に（記入する人間の方に）問題があるので、すべてに対応しかけている
けど、なりきってはいないような感じですね。
　　MS-IMEもSjisはSjisだけみたいです。
　　逆に、「Sjisデータの検索じゃあ、何か不足があるのか」という事もあるので、
　　JIS外漢字に拘る場合なら、ユニコードデータも必要になるかも知れませんね。

　　すべての文字コードに対応した、高速Grepは高速にはならないような気もするの
で、私はSjis一本勝負で行きたいですね。
＿＿＿＿＿＿

　　

RE:20452 Grepはもっと早くならないか

Kamonohasi さん　05/11/18 21:19

こんばんは、いつもお世話になっております、カモノハシです。

>　　Atok辞書がユニコード文字なのか、jis+ユニコードなのかハッキリさせないと
>いけない事態ですね。
>　　それとも、Atok は、文字入力して確定した文字を、ユニコードかSjisか判定し
>て、検索データとして送り出すんでしょうか？
なにか大きな食い違いがあるような……？
データを検索するのはIME(この場合ATOK)ではありません。
検索をするソフトが全ての文字をsjisとして検索するなら、IMEがいくらUnicodeに対
応してようが関係ありません。
確かに
sjisの「あ」
unicodeの「あ」
は違いますが、すくなくとも秀丸は両者を区別して扱ってないと思いますが。
ファイルから読み書きするときだけエンコードを変換しているんじゃないかな？(憶
測です)
何がしたいのかいまいち分からないのですが……。
一つのファイルで部分的にsjisだったりunicodeだったりする規格外のファイルを検
索したいのですか？
そうでないかぎり、IMEがUnicode独自文字が扱えて検索ソフトがその文字コードに対
応しているなら、問題なさそうなんですが……。

RE:20407 Grepはもっと早くならないか

ENCODINGSHIFTJIS さん　05/11/19 08:51

fhew　氏
Satori - Indexing Service Utility
が見えなくなっているようなので、現状の確認ページ
WindowsのIndexingサービスは動かせるようです、シダエモン

WindowsをUNIXっぽく
Namazu
http://qwerty777.s57.xrea.com/winunix/namazu.htm

RE:20454 Grepはもっと早くならないか

秀丸担当 さん　05/11/21 10:27

>そうでないかぎり、IMEがUnicode独自文字が扱えて検索ソフトがその文字コードに対
>応しているなら、問題なさそうなんですが……。

V5.11βの修正はgrepに関してのことでしたが、検索はKamonohasiさんの言われ
る通り、従来からできています。
たぶん検索ダイアログボックスに目的の文字が入力できるかどうかということが
問題だと思うのですが、NT系のOSで、かつUnicodeの入力に対応したIMEであれば
できると思います。

RE:20406 Grepはもっと早くならないか

inouen さん　05/11/21 12:52

色々とGREP高速化について議論されていますが、既に開いているファイルの場合は、
検索機能と同様な処理により高速化出来るのではと思われますので検討をお願いしま
す。

それは大容量ファイルのGREP結果について以下のようなデータが得られていますので：
(ディレクトリ下に目標のファイル1個のみ収容、サブディレクトリなしの場合)

6文字の単語サーチ時、一致行　1行

検索コマンドでのサーチ時　　約1秒、
ファイル指定GREP時：　　　　約11秒
現在の内容でのGREP時　　　　約28秒
(エディタ表示からブランクのGREP表示窓が現れるまで17秒、
GREP表示窓にサーチ結果が出力されるまで11秒、合計約28秒）

約１６６MBの英数字のみのログファイルですべてメモリ上に読み込み済み、
ディスクアクセスなしの状態（のはず）、1行の文字数平均８０文字、最大140文字、
折り返し指定：　256文字、サーチ：単語単位、大文字/小文字の区別あり
サーチ単語等の位置：ファイルの最後99.9%付近
主記憶１GB、AMD Athlon2.8GHz　秀丸(5.11beta1)のみ実行状態の条件でサーチ

漢字指定、20文字程度の文字列指定、10箇所の一致箇所、大文字/小文字の区別なし
等と条件を変えると検索コマンドでの時間は2秒程度(最初の行サーチ迄）となり、
ファイル指定GREP、現在の内容でのGREP時にも同様に１－２秒遅くなる程度で
傾向は変りません。(同じくファイルの最後付近にサーチ文字列がある場合）

参考のため：(同じ１６６MBのファイルの操作時間）
最初の秀丸での読み込み終了までの時間：　約３３秒
2回目の読み込み終了までの時間：　　　　約２０秒
　　（同じファイルの表示を終了して再度開く操作を実行）
ファイルをエクスプローラでコピー　　　　約8秒

これらの時間はCPU速度、主メモリ（システムキャッシュ）サイズ、
ファイルの格納状態(連続セクタか、何ブロックに分かれているか）
等によりかなり変ってくることとは思われます。

以上から次のような点につき検討をお願いします。

１．現在の内容でのGREP時、少なくともファイル指定GREPの場合よりも遅くならない
ようにする。
　　さらには検索コマンドでのサーチと同じオーダーの時間で実行可能とする。

２．ファイル指定GREP時、既にそのファイルが開かれている場合、新たにファイルを
開くことなく
　　検索コマンドと同じオーダーで高速にGREPを行うようにする。

３．高速GREPモード機能を追加する。
大文字/小文字の区別あり
Shift JIS only（？）
論理行単位の行番号、表示モード　等に条件を限定

但しこの効果は2倍までは上がらないと思われます。

ファイルコピー時間が8秒なので読み込み時間は4秒前後、サーチ時間2秒と仮定
した場合
合計6秒程度：
ファイル指定GREP時間が約11秒なので最高約2倍程度の高速化が可能と考えられ
ます。

追加処理としては比較的容易に実現可能だと思われますし、それなりの効果はあ
ると考えられ
ますので、このようなモードでの使用頻度がどの位あるか等も考慮して、
出来れば追加検討していただくようお願いします。

　　１，２項はぜひ実現する方向でご検討頂けたらと考えています。

以上よろしくお願いします。

RE:20476 Grepはもっと早くならないか

アルビレオ さん　05/11/21 14:36

アルビレオです。

>２．ファイル指定GREP時、既にそのファイルが開かれている場合、新たにファイルを
>開くことなく
>　　検索コマンドと同じオーダーで高速にGREPを行うようにする。

すでに開かれているファイルウィンドウは内容が編集されている可能性があるた
め、問題があります。
さらにたとえ開いているテキストが更新されていなくても、ファイルの方が書き
換わっている場合もあります。
「編集中テキストの検索」と「ファイルの検索」を同一視するわけにはいかない
でしょう。

結果的にこの方法で高速化するためには
・対象ファイルをすでに秀丸エディタで開いている
・すでに開いているテキストが更新されていない
・すでに開いている内容と比較して、ファイルの内容が変更されていない
というすべての条件を満たす必要があり、検索対象ファイルが大量だと条件チェ
ックのためにかえって遅くなってしまうケースもありそうです。

RE:20472 Grepはもっと早くならないか

なむnomoto さん　05/11/21 21:01

なむnomotoです

>V5.11βの修正はgrepに関してのことでしたが、検索はKamonohasiさんの言われ
>る通り、従来からできています。
>たぶん検索ダイアログボックスに目的の文字が入力できるかどうかということが
>問題だと思うのですが、NT系のOSで、かつUnicodeの入力に対応したIMEであれば
>できると思います。

　　秀丸で検索できない、という言い方が悪いのかも知れませんが、
　　要するに、検索ダイアログボックスに目的の文字が目的のコードで
　　入力するには、表示がアラビア語ならばアラビア語のIMEか、または
　　ユニコードの表示なら、ユニコードで記述しないと「できない」と
　　いうつもりでした。

　　秀丸でも検索できる、という言い方だと、その言語のIMEを使えば
　　できるはず、という意味です。

　　日本語漢字しか入力できない私には、GBやBIG5などが表示されても
　　検索できないということを、言いたかったのです。
　　ユニコードの漢文が表示されていても、ATOKでも検索は無理じゃないかと思うの
ですが、
　　クラフトさんが、
　　検索出来る見たいと、言われるので解らなくなっています。

　　しかし、Shift-jis で外国人がデータ検索できないと言われて、
　　ユニコードデータの提供を希望されても、私はShift-jisのみしか提供しません。
　　ユニコードにはある漢字を、私が補うには面倒な感じだからです。
　　そのShift-jisデータをユニコードに変換して、自由にやってもらえれば良いの
です。
　　　　・・・・・という具合に、古典のテキストデータ化だけでも結構面倒。(^^;)
＿＿＿＿＿＿

RE:20480 Grepはもっと早くならないか

小電流 さん　05/11/21 22:23

>　　日本語漢字しか入力できない私には、GBやBIG5などが表示されても
>　　検索できないということを、言いたかったのです。
>　　ユニコードの漢文が表示されていても、ATOKでも検索は無理じゃないかと思う
>のですが、
>　　クラフトさんが、

Win XPには標準で文字コード表があり、フォントとOSでマッピングされている任意の
文字が入力できます。なので、Unicodeの文字（JIS外文字）が入力できない、という
のは当たりません。
それに、Atok文字パレットに（MS IMEにも）Unicode表があります。
尤も、実際その文字が表示されているならコピー&ペーストで検索かけられるはずだ
と思うんですけど。

>　　しかし、Shift-jis で外国人がデータ検索できないと言われて、
>　　ユニコードデータの提供を希望されても、私はShift-jisのみしか提供しません。
>　　ユニコードにはある漢字を、私が補うには面倒な感じだからです。
>　　そのShift-jisデータをユニコードに変換して、自由にやってもらえれば良いの
>です。

そんな意地悪しないでUnicodeに変換すればいいのに

RE:20478 Grepはもっと早くならないか

秀丸担当 さん　05/11/22 10:09

>１．現在の内容でのGREP時、少なくともファイル指定GREPの場合よりも遅くならない
>ようにする。
>　　さらには検索コマンドでのサーチと同じオーダーの時間で実行可能とする。
>
>２．ファイル指定GREP時、既にそのファイルが開かれている場合、新たにファイルを
>開くことなく
>　　検索コマンドと同じオーダーで高速にGREPを行うようにする。

確かに、ある程度高速になるかもしれません。
アルビレオさんの言われているように、実際のファイルとの一致なども考えない
といけないと思います。
grep中に、開いている秀丸エディタで編集作業を続けることもできるので、不安
定要素となる危険もありそうです。
ネタとして参考にしたいと思います。

>３．高速GREPモード機能を追加する。
> 大文字/小文字の区別あり
> Shift JIS only（？）
> 論理行単位の行番号、表示モード　等に条件を限定

これは現状でそのように指定すればそうなります。
現状で行番号は論理行しか扱っていないです。

RE:20483 Grepはもっと早くならないか

秀丸担当 さん　05/11/22 10:33

>　　秀丸で検索できない、という言い方が悪いのかも知れませんが、
>　　要するに、検索ダイアログボックスに目的の文字が目的のコードで
>　　入力するには、表示がアラビア語ならばアラビア語のIMEか、または
>　　ユニコードの表示なら、ユニコードで記述しないと「できない」と
>　　いうつもりでした。

ファイルをUnicodeで記述しなくても、どのエンコードであっても検索はできて
いると思います。
いかなるエンコードをされたファイルであっても、文字化けせずに開けていれば、
検索ダイアログボックスに、Unicode文字表から目的の文字を探して入力すれば
検索できます。
必ずしもエンコードごとに専用のIMEが必要ということはないです。

RE:20487 Grepはもっと早くならないか

なむnomoto さん　05/11/22 13:06

なむnomotoです

>>　　秀丸で検索できない、という言い方が悪いのかも知れませんが、
>>　　要するに、検索ダイアログボックスに目的の文字が目的のコードで
>>　　入力するには、表示がアラビア語ならばアラビア語のIMEか、または
>>　　ユニコードの表示なら、ユニコードで記述しないと「できない」と
>>　　いうつもりでした。
>
>ファイルをUnicodeで記述しなくても、どのエンコードであっても検索はできて
>いると思います。
>いかなるエンコードをされたファイルであっても、文字化けせずに開けていれば、
>検索ダイアログボックスに、Unicode文字表から目的の文字を探して入力すれば
>検索できます。
>必ずしもエンコードごとに専用のIMEが必要ということはないです。

　　実験してみました。
　　云われるとおりです。分からないのは、「grep実行」ヘルプには、
>>　[その他]-[動作環境]-[ファイル]-[エンコーディング1]-[ファイルの内容を
>>解析してエンコードの種類を自動認識する]が有効になっていると、grepの実行
>>においてもエンコードの種類の自動認識が働きます。
>>
>>　検索可能な文字はShift-JISにある文字コード（つまり日本語）だけです。
>>エンコードの種類の自動認識が働いても、Shift-JISにない文字コードは検索でき
>ません。

　　jis文字でのみ検索可能とあるので、このあたりの理解が私に不足しているよう
です。
　　実験では、Unicodeでファイルを保存したUnicodeファイルです。
　　一旦保存して再度開いたUnicodeファイルで実験しました。
　　”Unicode文字表から目的の文字を探して入力すれば"とありますが、実は、
　　Unicode独自の文字（=jisにない文字）のみならず、通常のjis内漢字も、語句も、
　　入力すると検索きできてしまいます。
　　使用IMEは、ATOK13です。

　　これは、秀丸が正しく検索しているのでしょうか？
　　　　　　　そうなら、ヘルプの説明をも少し詳しくして欲しいです。
　　Unicodeに正しく変換されたのか、心配もあります。
＿＿＿＿＿＿

RE:20491 Grepはもっと早くならないか

秀丸担当 さん　05/11/22 16:53

>　　これは、秀丸が正しく検索しているのでしょうか？
>　　　　　　　そうなら、ヘルプの説明をも少し詳しくして欲しいです。
>　　Unicodeに正しく変換されたのか、心配もあります。

V5.11β1によって、いままでできなかったShift-JISの文字以外のgrepができる
ようになりました。
ヘルプは修正していませんでした。修正しておきます。

少し誤解があったかもしれませんが、「検索」と言っていたのはgrepのことでは
なく、[検索(S)]→[検索(F)...]で行うファイルを開いた後に行う通常の検索の
ことです。

RE:20492 Grepはもっと早くならないか

なむnomoto さん　05/11/22 18:22

なむnomotoです

>V5.11β1によって、いままでできなかったShift-JISの文字以外のgrepができる
>ようになりました。
>ヘルプは修正していませんでした。修正しておきます。

　　有り難うございます。

>
>少し誤解があったかもしれませんが、「検索」と言っていたのはgrepのことでは
>なく、[検索(S)]→[検索(F)...]で行うファイルを開いた後に行う通常の検索の
>ことです。

　　自動認識で、Unicodeファイル（のはず）を、Atok辞書文字でgrepできます。普
通の検索も出来ます。
　　Big-5code,GBcode,韓国語ファイルは、Atok辞書文字で検索もgrepもできません。
　　つまり、ユニコードファイルだけは検索・grepに使えるようです。
　　この認識で、宜しいですか？
　　　　Atok辞書の事を秀丸担当さんに尋ねるのは間違っているかも知れませんけど、
念押しで教えて下さい。　(^^;)

　　

RE:20483 Grepはもっと早くならないか

なむnomoto さん　05/11/22 18:39

　　　　　　　　　　　　　　　　　　　なむnomotoです

>Win XPには標準で文字コード表があり、フォントとOSでマッピングされている任意
>の文字が入力できます。なので、Unicodeの文字（JIS外文字）が入力できない、と
>いうのは当たりません。
>それに、Atok文字パレットに（MS IMEにも）Unicode表があります。

　　その場合、秀丸のあいまい検索は効くんでしょうか。
　　例えば、「逾遙神根轉鈍」を１字ずつ入力すれば良い、という事ですか？
　　Unicodeファイルは、Atok文字でGrepでるようです（確かめました）が、
　　Big5,GB,韓国語は検索もできません。やはり、専用IMEが必要のようです。

>尤も、実際その文字が表示されているならコピー&ペーストで検索かけられるはずだ
>と思うんですけど。

　コピー&ペーストするために、その語句があるかないか解らない状態で原文を捜す
のは、
　ちょっと、難しいのではありませんか？　

>>　　そのShift-jisデータをユニコードに変換して、自由にやってもらえれば良い
>のです。
>
>そんな意地悪しないでUnicodeに変換すればいいのに

　　変換後のUnicodeファイルには、？に化ける漢字が結構多いのです。
　　？文字についてデータ保証するには、文字入力しなければなりません。
　　その文字を１つ１つUnicode漢字表から捜して入力するのは、１Mbyteファイルで
も、
　　時間のかかる作業になります。それが１０Mbyteあったら、断るしかないです。
原典確認は世界中必須のことですし。

RE:20493 Grepはもっと早くならないか

秀丸担当 さん　05/11/22 18:45

>　　自動認識で、Unicodeファイル（のはず）を、Atok辞書文字でgrepできます。普
>通の検索も出来ます。
>　　Big-5code,GBcode,韓国語ファイルは、Atok辞書文字で検索もgrepもできません。
>　　つまり、ユニコードファイルだけは検索・grepに使えるようです。
>　　この認識で、宜しいですか？
>　　　　Atok辞書の事を秀丸担当さんに尋ねるのは間違っているかも知れませんけ
>ど、
>念押しで教えて下さい。　(^^;)

V5.11β1で、Big5でもGB2312でも韓国語でもgrepできるようになりました。
Atok辞書文字というのは何を指すことなのかちょっとわかりませんでした。

grepダイアログで、エンコードの種類が自動認識になっている場合、自動認識に
失敗すればgrepでヒットしないと思います。
明示的にBig5などを指定すればできると思います。

自動認識でも、自動認識の設定でBig5などが認識可能なように設定されていれば
成功するかもしれません。認識が成功するかどうかは、[ファイル]→[開く]で自
動認識で開いてみると認識に成功しているファイルであるかどうかを確認するこ
とができます。

正規表現やあいまい検索については、Big5などではうまく動かないかもしれない
です。

RE:20495 Grepはもっと早くならないか

なむnomoto さん　05/11/22 20:04

なむnomotoです

>>　　自動認識で、Unicodeファイル（のはず）を、Atok辞書文字でgrepできます。普
>>通の検索も出来ます。
>>　　Big-5code,GBcode,韓国語ファイルは、Atok辞書文字で検索もgrepもできません。
>>　　つまり、ユニコードファイルだけは検索・grepに使えるようです。
>>　　この認識で、宜しいですか？
>>　　　　Atok辞書の事を秀丸担当さんに尋ねるのは間違っているかも知れませんけ
>>ど、
>>念押しで教えて下さい。　(^^;)

>V5.11β1で、Big5でもGB2312でも韓国語でもgrepできるようになりました。

　　おおお！　素晴らしい。その通りです。
【検索】
　　やってみました。Big5でもGBでも韓国語でもユニコードでも、正しく表示されて
いれば、Atok入力文字で検索もできます（前回発言訂正）。
　　　正規表現・あいまい検索はダメみたいです。

【Grep】
　　Grepは、エンコード一致してファイル内容が正常に表示されていても、　
　　Grepダイアログのエンコード「自動認識」ではなく、敢えてそのエンコードを指
定しないといけないですが、
　　　　ちゃんとGrep結果も表示されます。
　　　　エンコードの種類を選べば、ちゃんとGrepしますね。強調表示も効いていま
す。
　　　　Grep後の結果は、そのエンコード文字なんですか？　jisのようにも見えま
すが。

>Atok辞書文字というのは何を指すことなのかちょっとわかりませんでした。

　　ええと(^^;)、　ワープロソフト一太郎に付いているIMEです。
　　MS-IMEは、日本語や漢文には（私には）ちょっと使いにくいので。
　　ま、どっちでも、Grepする方法が解りました。
　　　秀丸さん、素晴らしい！

　　あいまい検索・正規表現は、SjisファイルではもちろんＯＫ！
　　　　　　　　　　　　　　・UTF-8でも、あいまい検索・正規表現Grep出来ます。
　　　　　　　　　　　　　　・Big5でもGBでも韓国語では、あいまい検索・正規表
現Grepはできません。
　　　　　　　　　　　　　　　エンコードのコード指定窓は、前回のコード指定が
固定されるようには
　　　　　　　　　　　　　　　ならないのでしょうか。繰り返す時に面倒です。

>grepダイアログで、エンコードの種類が自動認識になっている場合、自動認識に
>失敗すればgrepでヒットしないと思います。
>明示的にBig5などを指定すればできると思います。

　ああそうか、自動認識に失敗してるんですか。

>自動認識でも、自動認識の設定でBig5などが認識可能なように設定されていれば
>成功するかもしれません。認識が成功するかどうかは、[ファイル]→[開く]で自
>動認識で開いてみると認識に成功しているファイルであるかどうかを確認するこ
>とができます。

　　いつもはSjisなので、必要なときだけエンコードの種類を指定した方が良いかも
ね。
　　Grepマクロで、エンコードが指定できるようになったので、この方法も使えます
ね。

>正規表現やあいまい検索については、Big5などではうまく動かないかもしれない
>です。

　　確かに　巧く行きません。
　　ユニコードUTF-8のファイルに、正規表現やあいまい検索が有効なのはなぜなん
ですか？　
　　　　　Utf-8 だからなんでしょうけど(^^;)

RE:20485 Grepはもっと早くならないか

inouen さん　05/11/22 23:45

＞ネタとして参考にしたいと思います。
よろしくお願いします。

>>３．高速GREPモード機能を追加する。
>> 大文字/小文字の区別あり
>> Shift JIS only（？）
>> 論理行単位の行番号、表示モード　等に条件を限定

>これは現状でそのように指定すればそうなります。
>現状で行番号は論理行しか扱っていないです。

３項はご指摘のように現状で指定により実現可能ですので取り消させてください。

＞アルビレオさんの言われているように、実際のファイルとの一致なども考えない
＞といけないと思います。

すでに開いているファイルの場合、秀丸内に取り込んでいるファイル内容に基づきGR
EPすることで
特に問題ないのではないかと考えられます。

ディスク内のファイルがログファイル/現在値情報ファイルのようにプログラム出力
により
変化する場合、秀丸読み込み時とGREP時の内容が変るのと同じように、確率は少ない
にしろ　
GREP後しばらくしてGREP結果でタグジャンプした先の文字列が変って別のものになって
しまうこともありそうです。

これは気にしても仕方なく、いずれにしろある時点のスナップショット：
現在の読み込み済みの内容を使って処理：GREPすることをはっきりさせておけば良い
と思います。

また、たとえディスクの最新情報でGREPしたにしろ、GREP内容をもとにタグジャンプ
した場合、
ファイルを読み返さない限り参照できるのは古い内容であり、目的の文字列はそこに
は無いことも
起こりそうです。

(変更済みのものは必要であれば名前を変更してセーブするなどの後）ファイルをク
ローズして
最新内容をGREP,参照することにより対応すればよいと思います。

また、二人の人が同じファイルを同時にエディットしていて...ということは考える
必要は
ないと思います。
もしこのようなことが起これば二人の変更の内、最後の人の変更しか残らずGREPでの
問題以前の
問題だと思います。
（CVS等ファイル管理システムの採用で、あるいはお互いに連絡しあうことで　
このようなケースが起こらないように対応されているはずだと思います）

＞すでに開いている内容と比較して、ファイルの内容が変更されていない
＞というすべての条件を満たす必要があり、検索対象ファイルが大量だと条件チェ
＞ックのためにかえって遅くなってしまうケースもありそうです。

個々のファイル毎に現在秀丸で開かれているかをチェックすればよいので、
大量のファイルでも問題ないと思います。

秀丸で開かれているどうかは　20-30個のエントリの秀丸で開いているファイルに対
応する
テーブルサーチ、秀丸内に変更済みでディスクに書かれていないものがあるかどうか
は、
変更ありのフラグチェックで可能と思います。
これらは１エントリサーチmicrosecオーダー、１ファイル当たり１０microsecオー
ダーで
処理可能だと思います。

複数の秀丸の窓が開かれている場合、プログラム間交信(1回１０microsecオーダー）
などを
交えて処理する必要があり、多少処理が重くなるとは思います。

ディスクアクセスは、数100回/sec, メモリ内キャッシュ使用を考えても数千回/sec、
数１０micro-１msecオーダー/回が必要だと思います。
ディスク内のファイルアクセスの場合には　インデックスアクセス、ファイル本体ア
クセス等
複数回のディスクアクセスが必要であり、ディスクファイル参照のほうが、秀丸の読
み込み済み
内容参照より一桁程度遅くなるのではと思います。

>grep中に、開いている秀丸エディタで編集作業を続けることもできるので、不安
>定要素となる危険もありそうです。

これは秀丸担当さんに色々と対応していただく必要がありそうですね。
エディット中の現在位置情報等をセーブしてGREPし、GREP後復元する、その間エディ
ット処理は
行わないようにロックしておく等の必要がありそうです。
(これらの処理を追加する必要がありますよ：との意味で不安定要素...と書かれてお
り、
とっくに分かっていますよと言われそうですが、

その他　すこし書きすぎてごめんなさい）

そのうちに実現されることを期待しています。

RE:20498 Grepはもっと早くならないか

アルビレオ さん　05/11/23 00:50

アルビレオです。

>＞アルビレオさんの言われているように、実際のファイルとの一致なども考えない
>＞といけないと思います。
>
>すでに開いているファイルの場合、秀丸内に取り込んでいるファイル内容に基づきGR
>EPすることで
>特に問題ないのではないかと考えられます。

私は問題だと考えています。
エディタで開いているかどうかで検索対象が変わってしまうことがわかりにくい
し、検索対象として「ファイル名」を指定しているのだからあくまでファイルの
内容を検索して欲しいです。
そもそもGREPとは「ファイル」を検索するものではないでしょうか？

また、一つのファイルを開いているウィンドウが一つだけとは限りません。
そのため検索結果はどちらのウィンドウでヒットしたのかを特定する必要も出て
きます。

>また、たとえディスクの最新情報でGREPしたにしろ、GREP内容をもとにタグジャンプ
>した場合、
>ファイルを読み返さない限り参照できるのは古い内容であり、目的の文字列はそこに
>は無いことも
>起こりそうです。

たとえばログファイルのような追記型の更新ならあまり問題もありません。
それに現状でもまったく同じことが起きるので今さら気にするのも変でしょう。

他にも速度のことなども触れられていますが、私としては「ファイルを検索した
つもりが編集中のテキストを検索してしまう」というのは非常に問題がある、そ
れ以外の要素はそれに比べればごく小さなことだと思っています。

もしもそういう機能をつけるとしてもあくまでオプション扱いで、標準の動作に
はして欲しくありません。
こういうポピュラーな機能で他のテキストエディタと動作が違うということで混
乱する人も少なくないはずです。

RE:20499 Grepはもっと早くならないか

inouen さん　05/11/23 10:27

inouenです。

>もしもそういう機能をつけるとしてもあくまでオプション扱いで、標準の動作に
>はして欲しくありません。
>こういうポピュラーな機能で他のテキストエディタと動作が違うということで混
>乱する人も少なくないはずです。

アルビレオさんが書かれていますように、秀丸で読み込み済みの内容のGREP結果でなく
ディスク内容のGREP結果を期待されている場合、だまって動作を変更してしまうのは
問題でしょうね。

たしかにオプションボタンで指定した場合に限るようにする必要があると思います。

それからこの高速化はあらゆる場合に有効とはいかないようです。

GREPするファイルのうち多くが秀丸で開かれて主記憶上に読み込み済みの場合に、
GREP時間が最大数十秒短縮できる場合がある。
対象ファイルが少ない場合はもともと時間は気にならない。
主記憶の何倍もの容量の大量のファイルをGREPする場合はこの高速化はあまり役に立
たない
といったところのようです。

1項に示しました（現在の内容）指定のGREPの高速化は比較的容易だと思われますし、
使う側からの問題もないはずですので、まずはこれを実現していただけたらと考えて
います。

以上よろしくお願いします。

RE:20496 Grepはもっと早くならないか

秀丸担当 さん　05/11/24 10:01

>　　　　Grep後の結果は、そのエンコード文字なんですか？　jisのようにも見えま
>すが。

Grep後の結果は、基本的にShift-JISです。
エンコードの種類を明示的に指定した場合は、その指定したエンコードの種類に
したほうがいいかもしれないですが。

>　　ユニコードUTF-8のファイルに、正規表現やあいまい検索が有効なのはなぜなん
>ですか？　

Unicodeのファイルは基本的にShift-JISに変換しつつ検索するので、なんとかで
きています。

RE:20502 Grepはもっと早くならないか

なむnomoto さん　05/11/25 18:21

秀丸担当さん
　　　　　　　　　　　　　　　　なむnomotoです

>>　　　　Grep後の結果は、そのエンコード文字なんですか？　jisのようにも見えま
>>すが。
>
>Grep後の結果は、基本的にShift-JISです。
>エンコードの種類を明示的に指定した場合は、その指定したエンコードの種類に
>したほうがいいかもしれないですが。

　　ほう、そうなんですか。Sjisなんですか。道理で便利な感じです。
　　Grep後のエンコードの種類を決めたい方も、あるかも知れませんね。
　　私は、Sjisの方が有り難いですけど。

>>　　ユニコードUTF-8のファイルに、正規表現やあいまい検索が有効なのはなぜなん
>>ですか？　
>
>Unicodeのファイルは基本的にShift-JISに変換しつつ検索するので、なんとかで
>きています。

　　なんと、Unicodeのままではなくて、Sjisに変換したデータを検索してるんです
か。ふうむ。
　　これだと、Grepスピードは遅くなりますね。多分。
　　しかし、新しい秀丸の機能が増えたので、ちょっと心強いです。
　　ありがとうございました。