フォーラムの返信を作成しました。
- 投稿
お返事どうもありがとうございます。
おっしゃる通りに
document.HighlightFind = false;
を最初に追加するだけだと、元のハイライトまで全て消えてしまうのですが、あわせて
document.HighlightFind = true;
も最後に追加した所、以前と同じように動くようになりました。
どうもありがとうございました。（トピックのタイトルと相談内容が一致しておりませんでした。すみません。）
いつもお世話になっております。
２年ほど前にこのスレッドでご相談させて頂いた件なのですが、
最近のバージョンアップで、また同じ問題が起こるようになりました。以下のようなコードで、
ハイライト状態に影響を与えないようにこっそりFindを実行するということができておりましたが、
最近また、Findのハイライトがそのまま残ってしまうようになりました。bHighlightFind = document.HighlightFind;
…
Find(…)
…
document.HighlightFind = bHighlightFind;お手数ですが、ご検討頂けましたら幸いです。
江村様
お世話になっております。
貴重なご教示をどうもありがとうございます。
これでより確信をもってスペックを選択できます。私も、昔いろいろなエディタを試した事がありましたが、
私にとって重要なGREP検索の使い勝手という点で、EmEditor一択となりました。
検索窓を含め表示フォントを自由に設定できる点、便利なファイルジャンプ機能、かなり長い文字列にも対応可能な正規表現などが決め手でした。スクリプトマクロの使い方等も覚え始めたら、研究効率は格段に向上し、もう完全に手放せません。
一般的にコンピュータリテラシーがとても低い分野なのですが、仕事仲間の間でも少し使う人は、やっぱり EmEditor だということで一致してます。
今後ともどうぞよろしくお願いします。>KawakamiTakahiro様
貴重な追加情報をどうもありがとうございます。
「１回目」より「２回目」の方が大幅に時間がかかっていますが、
これは数字が逆になっているという事でよろしいでしょうか？この件、なかなかスペックから予測が難しいものなんですね。
どうもありがとうございます。> snow様
いろいろと親切にご教示頂きまして、ありがとうございます。
大変助かりました。お恥ずかしい限りです。お話をお伺いして、シングルスレッド性能ももちろん良いに越したことは無いが、
やはり、私の場合も内蔵ストレージの速度の方をより重視すべきかな、という考えが強まりました。（EmEditorの検索以外にも、全般的に起動速度等がかなり速くなりそうですし）
どうもありがとうございます。>KawakamiTakahiro様
ご教示頂き、どうもありがとうございます。
>②の数秒以下、というのはキャッシュされた情報を参照しているために速いのだと思います。
>CPUキャッシュについてはどちらも同じ16.5MBですから余り変わらないかと思います。
>今ご使用のCPUのキャッシュは4MBのようですからかなり増えます。
>検索が数秒で終わる、という状況が多少は長く保てるのではないでしょうか。
なるほど、一時的情報が保存されるのは「CPUキャッシュ」なのですね。（RAMとかかと思ってました）①の時シングルスレッドで動いているので、周波数の高い方を選ぶべきだろうか、という点は実は私も考えたのですが、
一方で、現在のスペックでも②が数秒で終わるという状況があるため、
「もしかして、時間がかかっているのはCPUが原因じゃなくてSSDからの読み込みか？ということは、気にするべきはむしろストレージの速度で、M.2の方を選ぶべきなのか？」
という事を考えて、恥ずかしながら自分では確信が持てず、ご質問させて頂いた次第です。①のスピードを直接的に左右する要素（現在のスペックで１～２分もかかってしまう原因）は、
やはりストレージの読み込み速度なのでしょうか？文字列は多分何でも同じじゃないかと思いますが、例えば
[哀挨愛曖衣位圍醫依委威爲畏胃尉萎偉椅彙意違慰緯唄銳衛箇介回灰會快戒改怪拐悔海界皆械繪開階塊楷解潰壞懷諧貝外害崖涯慨蓋該槪骸掛刈危机希季軌鬼歸喜揮貴毀輝宜僞義疑儀]
(80文字)
なら問題ありませんが、[哀挨愛曖衣位圍醫依委威爲畏胃尉萎偉椅彙意違慰緯唄銳衛箇介回灰會快戒改怪拐悔海界皆械繪開階塊楷解潰壞懷諧貝外害崖涯慨蓋該槪骸掛刈危机希季軌鬼歸喜揮貴毀輝宜僞義疑儀戲擬犧議系係契計惠啓揭溪繼詣稽憩鷄個鎖才]
(100文字)
だと、ジャンプ先でハイライトされません。検索オプションは、
ファイルの種類： *.txt
「サブフォルダも検索する」にチェック、
「正規表現」にチェック、
エンコード：設定されたエンコード、
出力方法：文書、
出力オプション：ファイル名と行を表示「高度」の中は
「指定したフォルダが存在しない場合にダイアログを表示する」のみチェック、
正規表現エンジンは規定(Onigmo)です。
よろしくお願いいたします。改行文字は含まれておりません。
v19.8までは問題なくできていた事です。このスレッドの最初に申し上げたように、
「ファイルから検索」の結果から(クリックやF10キーで)ジャンプした時に、検索文字列がハイライトされなくなった問題です。
v19.9.2で修正して頂き、「解決した」とお答えしましたが、実は検索条件によっては解決されていなかったというご報告です。ご検討頂けましたら幸いです。
度々すみません。
また最初の１点目の問題なのですが、解決したと思っていたのですが、
正規表現で[ ]の中がだいたい85文字あたりを超えると、やはりジャンプ先で検索文字列がハイライトされなくなります。
過去のバージョン(ver. 19.8)では数千文字あっても問題ありませんでした。ご検討頂けましたら幸いです。
お返事どうもありがとうございます。
そうです。検索した文字列のハイライト状態に影響を与えないマクロにしたいということでした。ご教示頂いたコードそのままだと、最初の fso.DeleteFile( sTemp ); のところで毎回「ファイルが無い」とエラーが出てしまうのですが、
上の２つの fso. … を
fso.CopyFile( sOrg, sTemp );
下の２つを
fso.CopyFile( sTemp, sOrg );
とすることで、以前と同様に望み通りの動きをするようになりました。
どうもありがとうございました。お返事どうもありがとうございます。
ご提示頂いたものでは、ハイライトは消えます。（正常な挙動かと思います）もとのハイライトを残したいのですが、
できていたものが突然できなくなり困っております。（前回提示させて頂いたコードは、with(document.selection) { } の中にあったのですが、
document.selection.が一部重複しておりました。拙いコードですみません。）いつもお世話になっております。
ご対応頂き、どうもありがとうございました。
１点目の問題は解決しました。しかし、２点目の問題がやはり解決しません。
以下のような極めて単純なコードなのですが、以前はずっと問題なく動いていたものが、
今はやはりFindの結果のハイライトがそのまま残ってしまいます。
何か考えられる原因、あるいは別のやり方はありませんでしょうか？
（カーソルのある位置の直前の < > で囲まれたタグを取得するというものです）xPos = document.selection.GetActivePointX(eePosView);
yPos = document.selection.GetActivePointY(eePosView);
bHighlightFind = document.HighlightFind;
Find(“<[^<]*?>”,eeFindReplaceRegExp);
tag = Text;
document.selection.SetActivePoint(eePosView, xPos, yPos, false);
document.HighlightFind = bHighlightFind;ご対応頂き、どうもありがとうございます。
愛用のエディタが更に便利になり、非常に嬉しいです。非常に些細な点で恐縮ですが、
１．「スペルチェックを行う」設定の時、合成された文字の下にだけ赤い波線がひかれます。これは消せないでしょうか？２．「文字数」の表示を、 例えば
13文字(9文字)
あるいは
9文字(13文字)
のように、合成文字を１文字と数えた場合の文字数も分かるようにすると良いのではないでしょうか。３．今回の合成文字に関する機能は、フリー版でもご対応頂くことは可能でしょうか？
宜しくご検討のほど、お願い致します。
追記です。上記の
>「DirectWriteを使用」のチェックを入れた状態だと、カーソルの行移動に伴って合成されたり分離したりを繰り返して、安定しません。
という状況は、行が２行以上にまたがるような、十分に長い場合にのみ該当するようです。
行が短い場合には、「チェックを外した状態」と同じで、常に分離したままです。よろしくお願い致します。
Chromeを使っておりまして、ブラウザごとに異なることは存じ上げませんでした。
おかげさまで、beta 4では古ハングルが正常に組み合わされるようになりました。どうもありがとうございます。
ただ、一つ不具合が出ていますので報告いたします。「古ハングル専用の終声」がついた字が、うまく合成されません。
（古ハングルでも、終声が現代語にあるものであれば問題有りません。）
「DirectWriteを使用」のチェックを外した状態だと、その終声だけが常に合成されず分離した状態です。
「DirectWriteを使用」のチェックを入れた状態だと、カーソルの行移動に伴って合成されたり分離したりを繰り返して、安定しません。以上です。
よろしくお願い致します。早速ご対応頂き、どうもありがとうございます。
なるほど、コードを変換してしまう機能ですね。
実は、私が申し上げておりましたのは、例えばこのフォーム内のように、コードはそのままで結合表示させる機能のことです。
それは可能そうでしょうか？古ハングルに関しましても、よろしくご検討のほどお願い申し上げます。
お忙しい中、ありがとうございます。
「表示」タブの「ダブル バッファリングを使用する」チェックボックスですね。試してみます。IMEは、ウィンドウズ付属のものでも、
私が通常使用している ナルゲセッ(날개셋)という入力機でも全く同じ症状がでます。もう少し試してみて、問題が解決しなかったら再度ご連絡いたします。
ありがとうございました！問題が解決しました。
エラーの原因は、
with(document.selection){
editor.ExecuteCommandByID(4096); // 新規文書
editor.OpenFile(fileName);
Find();
}
となっていたことだったようです。結局、
editor.OpenFile(fileName, 0, eeOpenAllowNewWindow);
document.selection.Find();
としました。お忙しい中、初歩的な質問にも丁寧にご返信いただき、恐縮です。
どうもありがとうございました。
