フォーラムの返信を作成しました。
- 投稿
ご返信ありがとうございます。
いえ、そのようなリンクはありません。
今回削除しようと考えている発言だけでなく、最近の発言にもリンクはありません。追記：この発言にはリンクが付きました。ツリーの最後が自分の場合だけ表示されるのでしょうか。
ただ、それにしても削除したいと思っている発言にはやはりリンクがありません。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〜となっています。
何かしら影響することはあり得ますでしょうか。今朝がた初期化して、まだほとんど編集していないため事象は発生していませんが、まずは気づいたことを報告させていただきました。
ご返信ありがとうございます。
たしかに少し前にWindowsを10-2004にアップしました。そちらの機能だったのですね。DirectWriteはオンです。オフにして様子を見ようと思います。
IMEはGoogle IMEを使用しており、MS-IMEの問題には該当しないと思われます。
よろしくお願いいたします。お疲れ様です。
20.7で挙動が変わったようです。
入力中のテキストがある場合に現象発生、クローズしようとすると、即クローズではなくエディタと同じサイズの中身のないウィンドウがあがるようになりました。
右上の閉じるボタンを押すとエディタに戻りますので、描画がおかしいだけで確認が機能するようになったのでしょうか。
未保存の文書をctrl+A→ctrl+Xと切り取って空にし、再度エディタをクローズすると閉じられました。何かハードの問題かとも思っていたのですが、今月新規に組んだPCでも同一でした。
CPUが新旧ともAMDであることが、関係あるかどうか…。以下観察していて気づいたことです。
・単に文書を編集しているだけでも発生する模様。
・編集領域の描画が止まると同時に（？）タブバーの表示もおかしくなり、さらに続けているとタブバーが消えて編集領域がせり上がったような状態になる。
・スタイルは「タブ」でも「ボタン」でも発生。
・タブバーは普段から結構表示がちらつき、とくに * が付くとき消えるときが目立つ。編集中の文書とその右だけでなく、全タブが再描画？
・別の問題か、正常時に一番右から順に閉じていくと、×が無反応になることがある。他の文書をクリックすると復活する（これは結構前から出ていた気がします）。だいぶん前に書き込んだものですが、一応追記させていただきます。
本件、ディスプレイ間で拡大率が異なる場合にのみ発生するようです。
当時はメインが4k-150%、サブがSXGA-100%だったのですが、2枚とも4k-150%にしたところ発生しなくなりました。追記です。
入力中のテキストがある場合、本来はクローズ時に確認が表示されるところですが、この状態のときにクローズするとそれが表示されずにウィンドウが閉じます。
そのため入力中の内容が失われます。
先程は他のアプリからフォーカスを戻した際に発生しました。
ですのでタブクリック時ではなさそうです。すみません、もう一点気になる箇所がありましたので、追記させていただきます。
プロジェクトプラグインの横スクロールは、何を基準に幅が決まるのでしょうか？
スクロールバーがなくても十分入りきっている状態でも、横スクロールできていますので。
