フォーラムの返信を作成しました。

1 件の投稿を表示中 (合計 318 個)
  • 作成者
    投稿
  • 返信先: プロジェクトプラグイン、ソート順 #30428
    snow
    参加者

    上記で期待通りになると書きましたが、フォルダのドロップ時にはまだ最下段になるようでした。
    今回はファイルについてのみの対応ということでしょうか?
    よろしくお願いいたします。

    返信先: プロジェクトプラグイン、ソート順 #30423
    snow
    参加者

    さっそくのご対応ありがとうございます。
    v21.5 beta 5 (21.4.905)にて、ドロップ時のソート順が期待通りになることが確認できました。

    フォルダの新規作成→名前設定時(既存フォルダのリネーム時)ですが、再度確認してみたらエクスプローラも自動で並び替えされなかったので(記憶違いでした)、
    これはこのままで良いかも知れません。

    よろしくお願いいたします。

    返信先: マクロを停止できない #30401
    snow
    参加者

    お世話になっております。
    遅ればせながら、オプション追加ありがとうございました。
    確認もできましたので、今度こそ解決しました。

    返信先: マクロを停止できない #30368
    snow
    参加者

    ご返信ありがとうございます。
    WindowsUpdateをはじめ、更新は比較的頻繁にチェックしています。
    が、これは発生し始めてからある程度時間も経ちましたし、そういう話でもないと思っています。

    心当たりもとくにありません。
    OS自体に手を加える類いのアプリを意識して入れたことはありませんし。
    例えば「AMD CPU+Photoshop」のような条件なら、意識するしないの問題ではないのであり得ますが…。
    PhotoshopでもJSマクロを作っていますが、同期だからかとくに問題はありません。

    提案ですが、カスタマイズに、「常にマクロを同期で実行」設定を増やすことはできないでしょうか。
    毎回マクロに#async=”off”を入れないといけないのも煩雑ですし、個人的には非同期のメリットを感じられる使い方をしていません。

    よろしくお願いいたします。

    返信先: マクロを停止できない #30361
    snow
    参加者

    ご返信ありがとうございます。
    alert文1行だけのマクロファイル(エラーなし)ですので、これ以上詳しく書けないのです…。

    返信先: マクロを停止できない #30353
    snow
    参加者

    すみません、終わったと思ったのですが、再び別のマクロで再現しましたので報告させてください。
    即時関数も使わず、単にalert(“A”)だけで、同様に終了できない状態になりました。
    なお、#async = “off”とすれば問題なく終了できました。
    よろしくお願いいたします。

    返信先: Visual Studio 2019コンソールでの実行 #30352
    snow
    参加者

    ひとまずvcvars32.batの出力結果をアウトプットバーに出力ということですと、以下で出てきます。

    var s = new ActiveXObject('WScript.Shell');
    OutputBar.clear();
    OutputBar.Visible = !0;
    var o = s.Exec('"C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Auxiliary\\Build\\vcvars32.bat"');
    OutputBar.writeln(o.StdOut.ReadAll());
    OutputBar.writeln(o.StdErr.ReadAll());
    
    返信先: Visual Studio 2019コンソールでの実行 #30345
    snow
    参加者

    もうひとつ、作業フォルダーはで

    s.CurrentDirectory = "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community";
    

    で指定できると思います。

    返信先: Visual Studio 2019コンソールでの実行 #30344
    snow
    参加者

    もしかして、「%~dp0vcvarsall.bat」がそのままファイル名だと思われたのでしょうか。
    「%~dp0」の部分は、%0(実行しているbat自身)のドライブとパスを示します。
    結局、実行しているvcvars32.batと同じディレクトリにあるvcvarsall.batのことです。

    …すでにEmEditorとは直接関係なくなっていますね(苦笑。

    返信先: Visual Studio 2019コンソールでの実行 #30331
    snow
    参加者

    こんばんは。
    問題は2つありました。
    ・Auxiliaryの前のバックスラッシュがエスケープされていない。
    ・Run()に半角スペースを含むパスを渡しているので途中で切れている。

    s.Run('"C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Auxiliary\\Build\\vcvars32.bat"');
    

    これでいかがでしょうか。
    (c:\\Progra~2\\Micros~2\\〜としても可能ですが、環境によって ~ の後ろの数字が違うと思います)

    返信先: Visual Studio 2019コンソールでの実行 #30319
    snow
    参加者

    上記、s.Run(“aaa.bat ” + document.FullName) でも行けたと思います。
    この場合は%1で展開できますね。
    (Photoshopのスクリプトとbatを共用したかった関係で環境変数経由にしたのでした)

    返信先: Visual Studio 2019コンソールでの実行 #30318
    snow
    参加者

    こんにちは。
    同様のことを実現するのに

    var s = new ActiveXObject(“WScript.Shell”);
    s.Environment(“PROCESS”).Item(“ARG”) = document.FullName;
    s.Run(“aaa.bat”);

    のようなマクロを用いています。
    aaa.batの中で、%ARG% と書いてフルパスを展開します。

    返信先: ダイアログ内のフォントサイズ #30317
    snow
    参加者

    ご対応ありがとうございます。
    個人的にはこちらで完璧だと感じました。

    返信先: ダイアログ内のフォントサイズ #30307
    snow
    参加者

    ご対応ありがとうございます。
    カテゴリリストも大きくなるのが確認できました。
    済みません、「プレビュー」というのは、フォント選択ダイアログにあるサイズ確認窓のイメージでした。
    「適用」は難しいとのことで了解です。

    よろしくお願いいたします。

    返信先: 行番号領域の最小幅を指定したい #30298
    snow
    参加者

    すみません、こちら返信を失念しておりました。
    ご対応ありがとうございました。

    返信先: ダイアログ内のフォントサイズ #30297
    snow
    参加者

    あっという間のご対応、本当にありがとうございます。
    150%以上で負担を感じなくなります。

    欲を言えば、カスタマイズや設定の左のカテゴリリストもこのスライダーに連動して欲しいと思います。
    また、一度指定すればそうそう変えることはないのでさらに可能なら…ですが、プレビューあるいは「適用」ボタンがあると目星を付けやすいと思います。
    よろしくお願いいたします。

    snow
    参加者

    ご返信ありがとうございます。
    カスタマイズの方ばかり探していました。

    返信先: 置換ダイアログ「数値範囲」 #30289
    snow
    参加者

    メインウィンドウ・他のダイアログにフォーカスが移らないのが確認できました。
    ご対応ありがとうございました。

    snow
    参加者

    個人的にはPC起動中ずっとEmEditorも起動しっぱなしなので、右クリックメニューは使っていません。
    一括選択してEmEdittor本体へドロップしています。
    これでもとくに制限なく開けそうです。

    返信先: マクロを停止できない #30287
    snow
    参加者

    本件メールでやりとりさせていただき、v21.3 beta 4での解消を確認できました。
    ありがとうございました。

    結果のまとめ。
    発生条件は「非同期実行かつ即時関数(下記)」でした。

    (function() {
    ここでエラー発生
    })();

    #async = “off”をご教示いただき、これでも防げました。
    江村様の環境では最後まで再現しなかったとのことで、違いが出る原因は不明ですが、
    ご対応により再現しなくなりましたのでそれは問題ありません。

    snow
    参加者

    自分でキャッシュ保持するのではなくWindows自体のキャッシュによるのですね。
    ありがとうございます。

    せっかくなのでここに書かせていただきます。
    実は今年初めまでの1年か1年半ほど、EmEditor以外の選択肢を模索していました(EmEditor v3に至る前にも大量に試用しました)。
    復帰させていただいた最大の理由がgrep速度です。
    操作等は慣れれば良いと言えますが、速度はどうしようもなく。

    バイナリファイルのみ10万ほどあるサブディレクトリがあり、EmEditorでは気にならなかったのですが、他の選択肢では(スキップしているはずなのに)大きく速度に影響しました。
    そこでこのサブディレクトリを移動して全体5,000程度にしたのですが、それでも同等の速度にはなりませんでした。
    他のディレクトリにもバイナリファイルが結構あるので、そこで差が付くのだと思います。
    我慢し切れず再び使わせていただくことになった次第です。

    返信先: HTML構文チェックのエラーについて #30253
    snow
    参加者

    ご対応ありがとうございます。
    最新21.2.0での解消を確認しました。

    snow
    参加者

    ご返信ありがとうございます。
    いえ、そのようなリンクはありません。
    今回削除しようと考えている発言だけでなく、最近の発言にもリンクはありません。

    追記:この発言にはリンクが付きました。ツリーの最後が自分の場合だけ表示されるのでしょうか。
    ただ、それにしても削除したいと思っている発言にはやはりリンクがありません。

    snow
    参加者

    1パーツだとそれほど差は出ないのですね…私ももう少し出るものかと。
    うちはCPU・ストレージに加えてマザーもメモリも数世代違うので、トータルなのでしょうね。
    ※今のPCで10秒「程度」は少々甘すぎでした。13〜15秒といったところでしょうか。

    なお、前のPCにはグラフィックボードを積んでいますが(Photoshop用のため)、grepには影響ないと思います。

    snow
    参加者

    こんにちは。

    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 件の投稿を表示中 (合計 318 個)