フォーラムの返信を作成しました。
- 投稿
いつもお世話になっております。江村です。
//
このマークの後ろのコメントで無効化しているはずのコードにまで反応してマクロが止まります。
そのためコメントになっているコードはすべて消さなければ動作しませんでした。
コメントを消すと普通に動きはしますが、これだと今後の保守性は極めて悪化するのでこの問題は解決しますでしょうか？
// から始まる後ろは一切反応してもらっては困ります。タブで区切って最後の列にコメントを記入することは可能です。例えば、次のようになります。
タロウ <tab> 太郎 <tab> // TEST 1 ハナコ <tab> 花子 <tab> // TEST 2よろしくお願いいたします。
お世話になっております。江村です。
正規表現の記載にエラーがあると多発してまともに動作しませんでした。
正規表現の記載方法の統一がされていないので
ご質問の内容が少し分かりづらいのですが、もしかするとバックスラッシュを2重にするかどうかの違いが原因ではないでしょうか？ マクロではバックスラッシュを2重に記述する必要がありますが、リンクファイルでは2重に記述してはいけません。ご確認いただけますでしょうか。
もし他の意味でご質問されている場合は、もう少し詳しく説明していただけると助かります。
どうぞよろしくお願いいたします。
いつもお世話になっております。江村です。
こちらで再現テストを行いたいので、[カスタマイズ] ダイアログの [タブ] ページで、既定から変更された設定がありましたら、教えていただけますでしょうか?
よろしくお願いいたします。
いつもお世話になっております。江村です。
snow様の方法をお試しいただいてもマクロのサイズが大きすぎて動作しない場合は、検索や置換に使用するデータが大きすぎる可能性があります。そのため、データとコードを別のファイルに分けて保存することをお勧めします。
EmEditorの連続置換機能では、リンクファイルを使用することができます。詳しくはこちらのビデオをご覧ください：
https://youtu.be/Rl6lS5YTu60?si=nbCrdgZOuus3Yong
このビデオのような操作をマクロに記録すると、次のようなマクロが記録されます：
batch_list = editor.filters; batch_list.AddReplace("(パス)\\replace_list.txt", "", eeFindReplaceCase | eeFindReplaceRegExp, eeExFindLinkFile); document.selection.BatchReplace(batch_list, eeReplaceAll, 0);replace_list.txtには、検索文字列と置換後の文字列をタブで区切って1行ずつ記載します。例えば、タロウ <tab> 太郎 ハナコ <tab> 花子このように記述して保存してください。ファイルは、UTF-16 (BOM付き) または UTF-8 (BOM付きまたはBOM無し) で保存してください。
snow様、ご協力いただき誠にありがとうございます。
今後ともどうぞよろしくお願いいたします。
いつもお世話になっております。江村です。
[カスタマイズ] の [マウス] ページで、[マウスでアクティブにする時カーソル位置を設定] オプションは既定のまま有効になっていますでしょうか?
よろしくお願いいたします。
いつもお世話になっております。江村です。
これは、v24.5.1 の不具合です。ご迷惑をお掛けして申し訳ありません。こちらでは既に修正しており、次のバージョンでは修正されます。
よろしくお願いいたします。
いつもお世話になっております。江村です。
[マクロ] ツール バーから基本ツール バーにボタンをドラッグ アンド ドロップできないですか? 文書タブのスタイルが、タブかボタンかは関係ありません。
私がご要望を誤解している可能性があるため、ご要望を明確化してください。よろしくお願いいたします。
いつもお世話になっております。江村です。
調査結果をご報告いただき、誠にありがとうございます。
（Ａ）の事実から、EmEditorがファイルを開く際にパーティションの情報（フォーマットすると変化する何らかのパラメータ）を利用していると推定されます（ほぼ確定）。
（Ｂ）の事実から、EmEditorがファイルを開く際にOSの再起動で変化する情報を利用していて、その情報が条件付きで行数位置算出に影響を与えていると推定されます。と推測されていますが、記録のために書いておくと、これは正しくありません。
実際には、問題はファイルのサイズと読み込み速度に依存しており、パーティションの情報などは関係ありません。ファイルの読み込みの初めは速く、その後速度が遅くなる場合にご指摘の問題が発生していました。この不具合は、v24.4.2 および v24.4.903 で修正済みです。また、今後同様の不具合が発生しないように、v24.4.904とまもなく公開する v24.5 では、ファイルサイズに内部的不整合がある場合に警告メッセージを表示する機能を追加しました。さらに、新機能の [検証] コマンドにより、開いたファイルの整合性やディスク、メモリの問題がないかを確認できるようになっています。ぜひ最新版に更新してご利用ください。
この度はご迷惑をお掛けし、申し訳ありませんでした。何かお気づきの点がございましたら、メールまたはフォーラムでご連絡ください。
今後ともよろしくお願いいたします。
いつもお世話になっております。江村です。
さきほど公開した最新の Preview 版 (v24.4.905) にて、ご希望の機能を追加しました。お試しください。
– 巨大ファイル コントローラーに [<<] ボタンと [>>] ボタンを追加しました。[>>] ボタンをクリックと、現在開いているサイズを超えないサイズで次の場所を開きます。[<<] ボタンをクリックすると、[>>] ボタンをクリックする前の場所に戻ります
よろしくお願いいたします。
いつもお世話になっております。江村です。
以下のように書いてください。
#language = "v8" function OnExecute() { var ext = ".txt"; // 閉じたい拡張子を指定 var docs = editor.Documents; for (var i = docs.Count; i >= 1; --i) { var doc = docs.Item(i); if (doc.FullName.toLowerCase().endsWith(ext)) { doc.Close(); } } } OnExecute();または
#language = "JScript" function OnExecute() { var ext = ".txt"; // 閉じたい拡張子を指定 var docs = editor.Documents; for (var i = docs.Count; i >= 1; --i) { var doc = docs.Item(i); var nLen = doc.FullName.length; if( doc.FullName.toLowerCase().substring( nLen - ext.length, nLen ) == ext ) { doc.Close(); } } } OnExecute();よろしくお願いいたします。
いつもお世話になっております。江村です。
さきほど公開した v24.4.2 および v24.4.903 で修正いたしました。
この度は、ご迷惑をおかけし、大変申し訳ございませんでした。今後もよろしくお願いいたします。
いつもお世話になっております。江村です。
プログラムの不具合について、私の環境でも再現できましたので、ディスクやメモリーのテスト結果については、もうお知らせいただかなくても大丈夫です。できるだけ早く修正し、次のバージョンを公開する予定です。
特定の条件下で巨大なファイルを開く際、ディスクキャッシュの影響でファイルの読み取り開始時は速くても、遅いハードドライブを使用していると、途中で一部の行を重複して読むことがある問題がありました。この不具合は、v22.4から存在しており、「遅いドライブから巨大ファイルを開く際の動作を改善するために進捗メッセージを改良」した際に発生しました。
yasuji様にはご迷惑をおかけし、大変申し訳ございませんでした。また、貴重なご報告をいただき、心より感謝いたします。
今後も何かお気づきの点がございましたら、フォーラムやメールにてご連絡ください。
引き続きよろしくお願いいたします。
いつもお世話になっております。江村です。
お問い合わせいただいたファイルのハッシュ値について、私のマシンでも確認しましたのでお知らせします。
ダウンロードした圧縮ファイル自体には違いはありませんでしたが、展開したXMLファイルのうち、enwiki-20241020-abstract.xml と jawiki-20241020-abstract.xml にはご指摘の通り違いがありました。この違いは、使用した展開ツールの違いによるもののようです。私は Windows 11 Pro (Version 23H2, Build 22631.4460) のエクスプローラーで展開しましたが、yasuji様はexplzhを使用されていました。そのため、explzhで展開したファイルの方が、7バイトずつ大きくなっていました。この違いを EmEditor で比較したところ、1行目の
<feed>(LF)の後に、同じ文字列
<feed>(LF)の1行が余分に挿入されていました。両ファイルとも、この7文字の違いです。
以下にハッシュ値を記載しますので、ご参考にしてください。
ダウンロードした圧縮ファイル: File name: C:\test\DownloadedZip\enwiki-20241020-abstract.xml.gz File size: 888851612 [Byte] SHA256 : 5db1f530bde86e127be0e1a9f9360b80ee3b053db63085d894ee81025730949f File name: C:\test\DownloadedZip\jawiki-20241020-abstract.xml.gz File size: 273506145 [Byte] SHA256 : bc9c0ae7be517c68bb2c79c16b9775099f590f240dee684baa8f5c03f44a6bc9 File name: C:\test\DownloadedZip\jawiki-20241020-pages-meta-current.xml.bz2 File size: 5041613044 [Byte] SHA256 : 37103e74e6d54c3d1cd60a5ed5ff036becd4cc1230396662182feced17f773ac 展開したXMLファイル (エクスプローラで展開) File name: C:\test\XML\enwiki-20241020-abstract.xml File size: 7201978416 [Byte] SHA256 : 15f1433a86b6c251653b1e8693bc83daf09c5d7c00ac5d9fb75e064600552d50 File name: C:\test\XML\jawiki-20241020-abstract.xml File size: 2495630385 [Byte] SHA256 : 555000242a58048d2adbb51f662e0388b5325c3a8b8dff60747ac4e42bbbff3d File name: C:\test\XML\jawiki-20241020-pages-meta-current.xml File size: 23544648340 [Byte] SHA256 : 72deffd3eb53649de07d13b51174e2e4085d080650b984f1b53263fc23e74033 展開したXMLファイル (explzhで展開) File name: C:\test\XML_explzh\enwiki-20241020-abstract.xml File size: 7201978423 [Byte] SHA256 : 87e58b7649e8d8d11a0a3df1a0d941cff1e057a0a8305b9fdfc83ee1db4b946a File name: C:\test\XML_explzh\jawiki-20241020-abstract.xml File size: 2495630392 [Byte] SHA256 : 10be66f671c9afaa1a1bf8f045e9816b9c46774d7f1e914111dd11afc90adc21 File name: C:\test\XML_explzh\jawiki-20241020-pages-meta-current.xml File size: 23544648340 [Byte] SHA256 : 72deffd3eb53649de07d13b51174e2e4085d080650b984f1b53263fc23e74033引き続き、EmEditorに問題がないかも調査いたします。
よろしくお願いいたします。
いつもお世話になっております。江村です。
まず、問題がハードウェア、ソフトウェア、EmEditorのどこにあるのかを明確にすることが重要です。そのため、yasuji様にはハードウェアの確認をお願いしております。もちろん、EmEditor側でも調査を進めていますので、その点はご安心ください。
> つまり、「あなたのマシンのハードウェアの問題であって、EmEditorの不具合ではありません。したがって、修正することはありません。」という、ご回答だと理解いたしました。
修正しないとは申し上げておりません。EmEditorの不具合であれば、もちろん修正いたします。また、不具合でない場合でも、進捗率が100%を超える現象が発生した際には警告メッセージを表示する対応を検討しています。
> 実は江村様が故意にXMLファイルの内容を7バイト削除して、不具合がないことを主張することが目的だった。
そのようなことは一切ございません。本当にそうお考えですか？信じがたいです。
> もし、私が何か言ってきたら、江村様はこちらの環境では、このようなファイルになっており、不具合は再現されませんでしたと主張して、私のマシンの環境に原因であると結論付けて、強引に納得させる目論見だったということですね。
そのような意図は全くありません。
> ディスクやメモリの問題の可能性があることが分かっていたなら、最初から２回目の内容で書くことができたはずです。２回目でテストするツールを増やしたのは、テストすることが手間であることがわかっていて、かつ数を増やせば一つくらい問題が出るだろうと考えて、手間で私を疲弊させてあきらめさせるか、問題が出たらそれの可能性があると説明して、EmEditorの不具合ではないと説明づけて解決するつもりだった。
まず、EmEditorの不具合の可能性も考慮しています。しかし、yasuji様の環境ではディスクによって結果が異なるため、ディスクの問題も考えられます。ハードウェアによる不具合の原因特定は容易ではありません。そのため、問題がどこにあるのかを切り分ける必要があります。ご協力をお願いしておりますが、お手数をおかけします。まずは、不具合が発生するディスクに共通する問題や、各ディスクのS.M.A.R.T.情報を教えていただければ幸いです。yasuji様なら様々なツールをご存知でしょう。どのツールでも構いませんので、できるだけ詳しいテストをお願いいたします。情報が提供されなくても、EmEditorに問題がないか、さらに調査を進めます。
> くれぐれもむやみに公表しないようにという脅しに聞こえます。
脅しではありません。フォーラムはユーザー間の交流の場であり、私との一対一のサポートの場ではありません。リスペクトを持ち、常識的な態度で議論に参加することが求められます。最近、yasuji様とのやりとりがフォーラムを独占し、攻撃的な内容が含まれるため、他のお客様に迷惑となっております。また、私とのメール内容を許可なく転載したり、意味のない巨大ファイルを投稿したりすることは他のお客様にとって迷惑です。EmEditorが不具合だと決めつけているのはyasuji様ではないでしょうか？ディスクやメモリの問題の可能性もあるのに、「〔致命的バグ〕」という衝撃的なタイトルをつけるのはリスペクトを欠いており、私は不快に感じました。
したがって、他のお客様に迷惑をかけないよう、yasuji様とはメールでやりとりすることを提案いたします。もし、EmEditorの不具合が明らかになりましたら、その対応も含め、フォーラムで公開いたします。
> １１月に報告した不具合及び、この不具合の対応をユーザが見て、今後ともEmEditorを使い続けたいと考えるユーザはいないのではないでしょうか。
私は常に誠意を持ってサポートを行っていますが、非常識な発言があまりにも多くなると、私も人間ですので、快くは思えません。それは他のお客様も理解していただけると思います。いずれにしても、すべての不具合報告にはしっかりと対応し、速やかに修正して更新していく姿勢には変わりありません。
よろしくお願いいたします。
いつもお世話になっております。江村です。
これは、正規表現エンジンの内部での処理に非常に大きな時間を要しているためだと考えられます。
そもそも、［正規表現で検索する追加行数(L)］には、それほど大きな値を想定していません。もっと小さな値を指定することを推奨します。何か追加でコメントがありましたら、本フォーラムではなく、私までメールをお送りください。
よろしくお願いいたします。
いつもお世話になっております。江村です。
こちらでは問題は再現しませんが、アクセス違反例外が発生したのでしたら、正規表現がそれほどに長い文字列を想定していないからだと考えられます。
もともと、［正規表現で検索する追加行数(L)］にはそれほど大きな値を想定しておりませんので、より小さな値を指定することをお勧めいたします。
何かご意見やご質問がありましたら、どうぞ私宛にメールでご連絡ください。
よろしくお願いいたします。
いつもお世話になっております。江村です。
この問題は、正規表現エンジンの内部処理にかなりの時間がかかっていることが原因と考えられます。もともと、［正規表現で検索する追加行数(L)］にはそれほど大きな値を想定しておりませんので、より小さな値を指定することをお勧めいたします。
何かご意見やご質問がありましたら、どうぞ私宛にメールでご連絡ください。
よろしくお願いいたします。
いつもお世話になっております。江村です。
こちらの環境では問題は発生していません。
「EmEditorは、メモリが不足しているか、一時フォルダのディスク空き容量が不足しているため、タスクを完了できません。この問題を解決するには、ページングファイルの初期サイズを増やす、ディスクから不要なファイルを削除する、または[カスタマイズ]ダイアログの[高度]ページでスレッド数を減らしてください。
これはメモリ不足が原因であり、EmEditor自体の不具合ではありません。仮想メモリーを増やしてお試しください。
何か追加でコメントがありましたら、私までメールをお送りください。
よろしくお願いいたします。
いつもお世話になっております。江村です。
どのようなツールでも構いませんので、お客様のマシンに問題がないか、できるだけ確認をお願いします。コンピューターの製造元がブート時や付属ソフトウェアで診断ツールを提供している場合は、それを使って完全なテストを行うことをお勧めします。中には、起動時に特定のキーを押すことでテストを開始できるコンピューターもあります。
また、ハードディスクのS.M.A.R.T.情報を確認し、異常がないかチェックしてください。特定のハードディスクで問題が発生しているようですが、問題のあるディスクに共通点はありますか？ハードディスクのファームウェアに問題がある可能性も考えられるので、可能であればファームウェアのアップデートをお願いします。詳しくはハードディスクのメーカーのWebサイトをご参照ください。
（３）については、江村様にどのようなご連絡をしたらよいのか？
私とのメールのやり取りが勝手に転載されたのであれば、私のメールアドレスをご存じのはずです。そちらにご連絡ください。
今後は、フォーラムではなく、直接私にメールを送ってください。
よろしくお願いいたします。
いつもお世話になっております。江村です。
私は、１０年近く使用している実績のあるMemTest86 Free(V9.3)を使用してメモリのテストを実施しました（以前メモリエラーを発見したバージョンに固定して使用）。
まず最初に、Windowsメモリ診断ツールでもテストしてみてください。ディスクによって結果が異なるということですので、CrystalDiskInfo などディスク診断ツールでも各ディスクをテストしてみてください。お使いのマシンに問題がないことを完全に確認することが重要です。
上記にも書きましたが、CaseNo 2.2のファイル読込中の最後付近のステータスバー表示内容が、「ファイルを読込中…(2,453 MB / 2,380 MB, 21,415,157 行) (103 %) 65 MB/s 残り時間: 0秒」と表示され、進捗率が100%を超える現象も発生しましたが、EmEditorの不具合ではないでしょうか？
本来のファイルサイズは2,380 MBであるにもかかわらず、2,453 MBが読み込まれているため、ファイルのロード中にファイルサイズが増加しているようです。CaseNo 2.2で不具合が発生しているということですが、これはEmEditorの問題というよりも、ディスクまたはメモリの不具合の可能性が考えられます。
よろしくお願いいたします。
