フォーラムの返信を作成しました。
- 投稿
あっという間のご対応、本当にありがとうございます。
150%以上で負担を感じなくなります。欲を言えば、カスタマイズや設定の左のカテゴリリストもこのスライダーに連動して欲しいと思います。
また、一度指定すればそうそう変えることはないのでさらに可能なら…ですが、プレビューあるいは「適用」ボタンがあると目星を付けやすいと思います。
よろしくお願いいたします。本件メールでやりとりさせていただき、v21.3 beta 4での解消を確認できました。
ありがとうございました。結果のまとめ。
発生条件は「非同期実行かつ即時関数（下記）」でした。(function() {
ここでエラー発生
})();#async = “off”をご教示いただき、これでも防げました。
江村様の環境では最後まで再現しなかったとのことで、違いが出る原因は不明ですが、
ご対応により再現しなくなりましたのでそれは問題ありません。自分でキャッシュ保持するのではなくWindows自体のキャッシュによるのですね。
ありがとうございます。せっかくなのでここに書かせていただきます。
実は今年初めまでの1年か1年半ほど、EmEditor以外の選択肢を模索していました（EmEditor v3に至る前にも大量に試用しました）。
復帰させていただいた最大の理由がgrep速度です。
操作等は慣れれば良いと言えますが、速度はどうしようもなく。バイナリファイルのみ10万ほどあるサブディレクトリがあり、EmEditorでは気にならなかったのですが、他の選択肢では（スキップしているはずなのに）大きく速度に影響しました。
そこでこのサブディレクトリを移動して全体5,000程度にしたのですが、それでも同等の速度にはなりませんでした。
他のディレクトリにもバイナリファイルが結構あるので、そこで差が付くのだと思います。
我慢し切れず再び使わせていただくことになった次第です。ご返信ありがとうございます。
いえ、そのようなリンクはありません。
今回削除しようと考えている発言だけでなく、最近の発言にもリンクはありません。追記：この発言にはリンクが付きました。ツリーの最後が自分の場合だけ表示されるのでしょうか。
ただ、それにしても削除したいと思っている発言にはやはりリンクがありません。1パーツだとそれほど差は出ないのですね…私ももう少し出るものかと。
うちはCPU・ストレージに加えてマザーもメモリも数世代違うので、トータルなのでしょうね。
※今のPCで10秒「程度」は少々甘すぎでした。13〜15秒といったところでしょうか。なお、前のPCにはグラフィックボードを積んでいますが（Photoshop用のため）、grepには影響ないと思います。
こんにちは。
EmEditorは新しいCPUほど効率が良くなると言えますし、何世代か違えばそれだけでも効果ありそうですが、
シングルスレッド性能は確かに効きそうだと思います。うちでファイル検索をする場合、以前のマシンと今のマシンを比較するとこんな感じです。
以前：AMD A10-7800 / RAM32GB / 3.5″ SATA3 HDD 20秒超？
今：AMD Athlon 200GE / RAM16GB / M.2 NVMe SSD 10秒程度？
ファイル数は半分くらい、日々更新しているファイル群ですが同期しているので内容は基本的に同一です。
CPUの差以上に向上していると感じています。
メモリ等も違いますので総合的な結果ですが、やはりストレージの違いが大きいのではと思っています。>一時的情報が保存されるのは「CPUキャッシュ」なのですね。（RAMとかかと思ってました）
対象とするフォルダ内のファイル一覧を自分でキャッシュしているのではと思っています。
特定のアプリが特定の用途にCPUキャッシュを占有、というのは違和感あるので。それから、こちらもちょっと気になったので…。
>M.2 SSD
>SSD
ここは「M.2 NVMe SSD」と「2.5″ SATA SSD」でしょうね。
M.2にはSATAとNVMeの2種類があり、前者は2.5″と大差ありませんので、老婆心ながら「NVMe」を確認されることをおすすめします。この件ですが、特定の文字種のみで構成されている場合にエラーとなるように見えます。
半角英字 1
半角数字 1
半角記号 0
全角かな 0
全角カナ 0
全角記号 0
漢字 1と置いて、足しても0の場合と言いましょうか。
ご返信ありがとうございます。
「数値範囲」のときは、もう一つダイアログが上がることに先ほど気づきました。
昨日は別PCで使用中のセカンダリディスプレイにこのダイアログが表示されていたため、気づかなかったようです。
問題は、この数値範囲ダイアログが表示された状態でフォーカスを本体ウィンドウに戻すと発生することが分かりました。http://mylph.my.coocan.jp/test/20211001.jpg
ダイアログを表示させた状態で、本体でctrl+zするとこうなります。
本来本体へフォーカス移動できない想定なのか、フォーカス移動してもきちんと編集できる想定なのか、どちらでしょう？
よろしくお願いいたします。なお、数値範囲ダイアログと置換ダイアログを両方閉じればきちんと復帰し、ctrl+zも消せましたので、エディタ本体の終了は不要でした。
ご対応ありがとうございます。
個人的に最近は業務でも個人でもJava等が多く、リソースリークはまずありませんが、VC++で書いていた頃を思い出しました。
お疲れ様です。先ほど正式版をインストールして「非常に暗い」をオンにし、様子見しています。
数日間経過して再度報告させていただこうと思います。ありがとうございます。
可能であればツリー内の複数位置から参照したので将来的に対応いただければと思います。
もちろんそれがないと何かができない、という話でもありませんので、軽い要望程度です。
よろしくお願いいたします。書き込んだ直後ですが、理由が分かった気がします。
プロジェクトの別のフォルダに、すでにフォルダを追加していました。
同じファイル（relativepath）が追加されている場合、たとえフォルダが別でも登録済みとみなされて追加できない、でしょうか。
つまりプロジェクト上、ひとつのファイルはどこかひとつのディレクトリにしか存在できないという制約でしょうか。夕方に発生しましたので報告させていただきます。
今のところ一番可能性が高いのはツール→カスタマイズ→表示→「非常に暗い（ベータ）」です。
タブ設定や文字色/背景色、フォント、ワークスペース等々を順次復元している間は一度も発生しませんでした。
今はいったんオフにしてあり、その後は発生していません。
このまましばらく様子を見て、発生しないようなら再びオンにしてみようと思います。五月雨ですみません。あと何点か。
・EmEditor本体の再起動時、各フォルダの開閉状態を再現
地味ですが、フォルダが多いと時々分からなくなります。
・ツリーメンバードラッグの、フォルダ移動以外の機能
編集領域にドロップしたら文書の挿入、それ以外のところなら通常の「開く」動作になると便利だと思います。
（クリックと間違えてドラッグしてしまうことが時々あります…）
・ファイルの新規作成・コピー機能
OS上のフォルダと対応して考えていると、どうしてもフォルダ上の操作で新規作成やコピーをしたくなります。
仮想ツリーである以上実際の保存先を指定するのは致し方ないとしても、新規ファイルを作成できないのはやはり「プロジェクト」としては不足に感じます。
なお、削除は二段階あった方が安全なので今のままで良いと思っていますが、選択できると便利かもしれません。ご検討いただければありがたく思います。
よろしくお願いいたします。ご返信ありがとうございます。
設定のリセット後、今朝の時点で、事象はまだ一度も発生していません。
このため構文チェックは関係がないと考えています。
昨夜、頻繁に使用していたマクロをひとつ登録して様子見しています。
以前の設定をインポートしないで、1日いくつかずつ手動で復元して行くつもりでいます（ほぼ1日に1回以上は発生していましたので）。
これでもし何かを復元した後に再現したら、お知らせしようと思っています。よろしくお願いいたします。
ご返信ありがとうございます。
プラグインは標準のプロジェクトのみ使用しています。
マクロは自前のものを含めいくつか登録し、ショートカットキーで使用しています。編集する頻度の多い10程度のhtmlファイルを常時開いてタブ表示しています。
このうち1つは22,000行超、1.6MBほどありますが、基本的に通常テキスト文書にタグを付けるスタイルのため、1行が数千文字あったりはしません。
日々の作業では、それに加えてその他のhtmlファイルやjs、cssファイルを確認したり編集したりしています。
総数は1,000超、プロジェクトで階層分けして開きやすくしています。
多量のため、特定の情報について確認する際は「ファイルから検索」も多用しています。上記1.6MBのファイルで発生することが多い印象ですが、単に一番編集頻度が多いためとも言えます。
クローズ確認について記載したとおり新規ファイルの入力中に発生することもあり、特定のファイルということはなさそうです。今回設定を初期化して気づいたのですが、上記はhtmlといっても、タグや属性について自前で拡張したものになっています。
（onloadイベントで処理し、標準のタグに展開するようにしています）
構文チェッカーは非表示にしていますが、働いていれば常にエラーが記録されていることになります。
上記1.6MBのファイルですとわずか374行目でTerminating validation due to too many errors〜となっています。
何かしら影響することはあり得ますでしょうか。今朝がた初期化して、まだほとんど編集していないため事象は発生していませんが、まずは気づいたことを報告させていただきました。
