フォーラムの返信を作成しました。
- 投稿
もしかして、「%~dp0vcvarsall.bat」がそのままファイル名だと思われたのでしょうか。
「%~dp0」の部分は、%0（実行しているbat自身）のドライブとパスを示します。
結局、実行しているvcvars32.batと同じディレクトリにあるvcvarsall.batのことです。…すでにEmEditorとは直接関係なくなっていますね（苦笑。
こんばんは。
問題は2つありました。
・Auxiliaryの前のバックスラッシュがエスケープされていない。
・Run()に半角スペースを含むパスを渡しているので途中で切れている。s.Run('"C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Auxiliary\\Build\\vcvars32.bat"');これでいかがでしょうか。
（c:\\Progra~2\\Micros~2\\〜としても可能ですが、環境によって ~ の後ろの数字が違うと思います）上記、s.Run(“aaa.bat ” + document.FullName) でも行けたと思います。
この場合は%1で展開できますね。
（Photoshopのスクリプトとbatを共用したかった関係で環境変数経由にしたのでした）こんにちは。
同様のことを実現するのにvar s = new ActiveXObject(“WScript.Shell”);
s.Environment(“PROCESS”).Item(“ARG”) = document.FullName;
s.Run(“aaa.bat”);のようなマクロを用いています。
aaa.batの中で、%ARG% と書いてフルパスを展開します。ご対応ありがとうございます。
カテゴリリストも大きくなるのが確認できました。
済みません、「プレビュー」というのは、フォント選択ダイアログにあるサイズ確認窓のイメージでした。
「適用」は難しいとのことで了解です。よろしくお願いいたします。
あっという間のご対応、本当にありがとうございます。
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++で書いていた頃を思い出しました。
お疲れ様です。先ほど正式版をインストールして「非常に暗い」をオンにし、様子見しています。
数日間経過して再度報告させていただこうと思います。ありがとうございます。
可能であればツリー内の複数位置から参照したので将来的に対応いただければと思います。
もちろんそれがないと何かができない、という話でもありませんので、軽い要望程度です。
よろしくお願いいたします。
