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

1 件の投稿を表示中 (合計 4,768 個)
  • 作成者
    投稿
  • Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    Windowsメモリ診断ツールなどで、メモリに異常がないかテストしてみてください。

    どうぞよろしくお願いいたします。

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    3つのファイルをダウンロードし、再現手順に従って試してみましたが、初回、2回目、再起動後の3回目ともに、ファイルの行数に変化は見られませんでした。実際に開いた直後にステータス バーに表示されたファイルサイズと行数は以下の通りです。

    
    jawiki-20241020-abstract.xml 
    2.32 GB (2,495,630,385 バイト), 20,871,118 行。
    
    jawiki-20241020-pages-meta-current.xml
    21.9 GB (23,544,648,340 バイト), 307,099,309 行。
    
    enwiki-20241020-abstract.xml
    6.70 GB (7,201,978,416 バイト), 85,969,885 行。
    

    また、ファイルを開いて編集せずに「名前を付けて保存」を行い、保存前後のファイルを比較しましたが、変更はありませんでした。テストに使用した環境は、CPU: 13th Gen Intel Core i7-1360P 2.20 GHz、RAM 16.0 GB、EmEditor Version 24.4.902 です。

    お使いのディスクに異常がないか確認していただけますでしょうか? Notepad++ で開いただけでは確認できないと思いますので、OSのツールや、chkdsk コマンドなどで、ディスクに問題がないか確認してみてください。

    どうぞよろしくお願いいたします。

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    「どうして、yasuji様は、そのように感じられるのでしょうか?」については、下記の通りです。
    1.過去の検索(置換)ウィンドウの切替キー操作時の不具合についてのメールでのやり取りの「#31387 – 〔要回答〕報告済:検索(置換)ウィンドウの動作不具合」において、ユーザのお好みの動作が異なるという理由と、この方法で代替できますよというご説明で修正をお断りされました(実際に修正いただいたのは、このメールの内容をトピック作成した後でした)。私個人としては、他のテキストエディターができていることで、無理を言っているつもりはなく、このような説明で修正を拒絶されたと受け止めて、かなりショックでした。

    yasuji様のお気持ちは理解しました。私の返信メールが言葉足らずで、お客様のお気持ちに寄り添えていなかったと思います。不快な思いをさせてしまい、申し訳ありませんでした。しかし、yasuji様のご要望を拒絶しているわけではありませんでした。私は、一言も「できない」とは書いていません。「これは、ユーザーによって好みの動作が異なると思います。」と書いただけで、「できる」とも「できない」とも書いていません。どうして、私の返信メール1件だけで、要望が拒絶されたと感じられるのでしょうか?

    私は、毎日、多くのお客様からご質問やご要望のメールを受信しています。お客様のご要望については、まずその内容をできるだけ正確に把握する必要があります。1件のメールだけでご要望を把握することは難しく、その後、返信メールを重ねて議論を行い、ご要望にお応えする形になります。1件のメールだけで、すぐに「できる」か「できない」かを判断することは、ほとんどありません。お客様から返信メールをいただかない場合には、そこで議論は終了してしまい、ご要望にお応えすることができなくなってしまいます。

    したがって、私の返信メールは、yasuji様のご要望の内容を確認するために書かせていただいたものであり、拒絶したものではありません。具体的には、

    「例えば、検索ダイアログが表示されている状態で、再び Ctrl+F を押した場合には、どうするのかとか、検索ダイアログで [置換 >>] ボタンを押した場合、さらに 検索ダイアログにフォーカスが設定されている状態で Ctrl+H を押した場合など検討しなければなりません。」

    の内容について、yasuji様のご意見をお聞かせいただきたかったのです。yasuji様のご意見を聞かずに、ご要望を実装することは難しいと思うからです。

    私がyasuji様にお願いすることは、私のたった1件のメールだけで、拒絶されたとか否定的に思わないでいただきたいのです。私が言葉足らずだったり、配慮が足りなかったのは認めます。申し訳ございませんでした。しかし、yasuji様も、これにめげずに、建設的な議論をしていただきたいと思っています。

    2.「ここ最近のEmEditorのリリース情報について」のトピックにおいて、「不具合は非常に軽微なもの」としてご説明しておりましたが、追及した結果、その非常に軽微なものの中に2バージョンでクラッシュバグが合計5件も含まれていたことが判明し、かなりショックでした。

    まず、バグの無いソフトウェアは存在しません。サンプルプログラムのような小さなアプリでしたら存在するかもしれませんが、市販されているような標準的なサイズのアプリの中では、どんなに優秀なソフトウェアにもバグは存在します。マイクロソフトが販売しているソフトウェアでも、Windowsは月に数回の更新を行っていますし、私が使用しているVisual Studioも月に数回、更新されていますが、それほど騒ぐほどの問題ではないと思います。EmEditorは、ユーザーからのご指摘やクラッシュレポートをいただいたら、すぐに対応して修正しています。履歴に不具合修正の項目が多いから、不安定ではないかと不安をお持ちになるかもしれませんが、実際にはその逆で、不具合を修正しないで更新がないソフトウェアの方が不具合が多いこともあります。

    また、クラッシュが致命的な不具合だと感じていらっしゃるかもしれませんが、私は必ずしもそうは思っていません。技術的には、クラッシュをさせないで無視して継続することも可能で、そうしているソフトウェアも存在します。しかし、EmEditorでは、不具合を意図的にクラッシュさせて、お客様にクラッシュレポートをフィードバックしていただくことにより、私がすぐに修正して更新するという良い循環を実現しています。そのため、他のソフトウェアよりもクラッシュが多く存在するように見えるかもしれませんが、ソフトウェアの品質は向上しています。

    私が「不具合は非常に軽微なもの」として説明したのは、非常に稀な条件のもとで発生する不具合のためです。既定の設定で、普通に行う動作ではまず発生することのないような不具合のため、非常に軽微なものと表現いたしました。しかし、この点についても私の言葉足らずであったことを認めます。申し訳ございませんでした。今後は、不具合の内容をできるだけ丁寧に説明いたしますので、お許しください。

    以上、何かと懐疑的な気持ちをお持ちのこととは存じ上げますが、今後もご要望に対して拒絶することはありませんので、これに懲りずに、EmEditorをご愛用いただきますようお願い申し上げます。

    最後に、私も人間ですので、今までのような攻撃的な発言が続いてしまうと、私もサポートする気がなくなってしまいます。このフォーラムは、ユーザー間の交流の場であり、私との1対1のサポートの場ではございません。フォーラムでのご質問やご意見に対して、必ずしも私からの返信が付くとは限らないことをご了承願います。また、過去のメールでのやりとりの内容をフォーラムに転載される場合は、事前に私の許可を取っていただきたかったと思います。勝手にメール内容が転載された点について、私も不快な気持ちになりました。攻撃的な内容の場合には、私のことはともかく、他のユーザーの方々へのご迷惑にもなりますので、フォーラムではなく、直接メールでいただいた方がありがたいです。その点、ご理解いただけると幸いです。

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

    返信先: 16TBファイルの対応について #32092
    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    「また、ファイルを開くだけで編集しない場合は、一時フォルダの空き容量は不要です。」が、正しいというならば「〔致命的バグ〕メモリ不足でもファイル読込を停止しない」の事象はどのように考えた良いでしょうか?
    この事象は、私が[ディスクベースを有効にする(B)]をOFFに設定したことが悪かったということでしょうか。

    私が先に説明した内容は、ディスクベースが有効になっている既定の設定を前提としていました。設定を変更されている場合は、最初にそのことをお知らせいただければと思います。ディスクベースが無効の場合、一時ファイルを保存するためのディスクの空き容量が必要です。また、ディスクベースが無効になっていると、数GB以上の大きなファイルを開くのはほぼ不可能です。巨大ファイルを扱う場合は、既定の設定の通り、ディスクベースを有効のままでお使いください。

    (Q1)
    物理メモリではなく仮想メモリ内で使用できるヒープメモリとなります。ただし、この設定がすべてのケースで反映されるわけではありません。特に、ファイルを開く際に必要な特定のメモリは、指定したサイズよりも大きくなることがあります。

    (Q2)
    仮想メモリのサイズに依存するため、私からは「できる」や「できない」とは断定できません。お客様ご自身でご確認いただければ幸いです。もしできない場合は、仮想メモリのサイズを増やしてPCを再起動することで、解決する可能性がありますので、お試しください。

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

    返信先: 16TBファイルの対応について #32091
    Yutaka Emura
    キーマスター

    Japelin様

    いつもお世話になっております。江村です。

    なんでそんなに攻撃的な投稿が多いのでしょうか。
    仕様に関する疑問が出ることはわかりますが、正直、ユーザーとして適切な範囲のリクエストなのか疑問です

    ご意見ありがとうございます。私とyasuji様とのやり取りが他のユーザーの皆様にも不快な思いをさせてしまい、申し訳ありませんでした。正直なところ、私のサポートにも限界を感じており、他のユーザーの方のご意見をいただけて良かったです。今後もご支援いただければ幸いです。

    引き続きよろしくお願いいたします。

    返信先: 16TBファイルの対応について #32085
    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    誠意を持ってお答えしているつもりですが、残念ながら、yasuji様には、私の回答が正確に伝わっていないようですので、誤解を避けるためにもう一度整理してご説明いたします。

    1TB~16TBのテキストファイルを開くには、RAMは64GB以上が必要で、一時フォルダの空き容量はファイルサイズの約16%(170GB~2716GB)が必要だと理解しました。

    RAMが32GB以下だと絶対に開けないわけではなく、64GB以上なら必ず開けるというものでもありません。ファイルサイズに加えて、行数や仮想メモリーの量など、他の要因も影響します。実際には、ファイルサイズは開く速度に影響しますが、開けるかどうかは行数が大きな要因です。また、ファイルを開くだけで編集しない場合は、一時フォルダの空き容量は不要です。

    「仮想メモリを増やす方法」で、ページングファイルサイズを80000MB(80GB)にすることが推奨されています。しかし、通常は8GB~16GBの物理メモリと同じサイズ、16GB~32GBの場合は自動割り当て(手動設定する場合は物理メモリの半分)が良いとされています。

    一般的なアプリでは、「16GB~32GBは自動割り当て(手動設定する場合は物理メモリの半分)」で問題ないかもしれません。しかし、EmEditorで巨大ファイルを扱う場合は、この設定では不十分で、80GB以上の仮想メモリーを推奨します。理由として、EmEditorは巨大ファイルを開く際に大量のヒープメモリーを必要とし、Windowsの仮想メモリーの増加速度が追いつかないため、メモリー不足が発生しやすい状況です。この問題は、Visual C++でCode Analysisを使用してビルドする際にも発生しやすいです。詳細は以下のWebページをご覧ください。

    https://learn.microsoft.com/ja-jp/troubleshoot/windows-client/performance/slow-page-file-growth-memory-allocation-errors

    このように、大きなメモリーを必要とするアプリでは、あらかじめページングファイルの初期値を大きく設定しておく必要があります。私はこれをOSの問題と考えています。

    HPに記載されている「16 TBまでのファイル」の宣伝は、EmEditorのカタログスペックの見栄えを良くするためだけの機能だと理解しました(8GB~32GBのRAMを搭載した一般的なPCでは開けないというご回答のため)。

    宣伝と思われるかもしれませんが、事実を記載しており、誇張ではありません。「メモリの許す限り」との注記もあります。事実を伝えないとユーザーに正しい仕様が伝わりません。EmEditorの仕様や機能をWebサイトに明記することが重要だと考えています。「8GB~32GBのRAMを搭載した一般的なPC」という指摘はその通りですが、EmEditorユーザーの中には64GB以上、さらには256GB以上のRAMを搭載したPCをお持ちの方も多くいらっしゃいます。EmEditorは、ユーザーの要望に応じて巨大ファイルを扱えるように長年改良を重ねてきました。これは決して「カタログスペックの見栄えを良くするためだけの機能」ではなく、多くのユーザーがこの機能を求めてEmEditorを選んでくださっています。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    修正を拒絶する理由は、修正工数が大きすぎてかつ複雑なため、やりたくないからでしょうか?

    そのようなことは思っていません。修正を拒絶することはありません。どうして、yasuji様は、そのように感じられるのでしょうか? もし、私の書き方が、yasuji様に、そのような印象を与えてしまったのでしたら申し訳ありませんでした。

    先ほど公開した v24.4.902 にて修正いたしました。

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

    返信先: 置換で改行が増加するとクラッシュする #32083
    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    先ほど公開した v24.4.902 にて修正いたしました。

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

    返信先: 正規表現検索の処理時間について #32079
    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    (Q1)
    ご指摘の通りです。

    (Q2)
    その通りです。

    (Q3)
    500行ごとに進捗を更新するように最適化しています。不具合ではありません。

    (Q4)
    検索用スレッド数が[スレッド数(N)]が1の場合、内部ではその値に1を足して2スレッドで検索しているのではないかというご質問ですが、これは考えられません。

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

    返信先: 16TBファイルの対応について #32078
    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    > 答えていただきたい回答になっていません。

    誠意を持ってお答えしたつもりでしたが、yasuji様のご期待に沿えず申し訳ありません。先に述べたように、64GB RAMのPCで動作確認を行いました。そのため、一般的なデスクトップPCに搭載されている32GBのメモリでも動作する可能性はあります。ただし、さまざまな条件があるため、必ずしも動作するとは限りません。メモリは多いに越したことはありませんし、8GBでは難しいかもしれません。また、これは物理メモリではなく仮想メモリに影響しますので、少ないメモリでも仮想メモリを大きくすることで動作する可能性が高まります。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    既に、こちらでは修正いたしました。次に公開されるバージョンでは修正されています。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    既に、こちらでは修正いたしました。次に公開されるバージョンでは修正されています。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    これは、使用されているフォントのデザインの問題です。設定のプロパティの [表示] ページの [行間] で調節可能です。ここには -1 のように負の値を入力することもできます。ただし、行頭の全角空白(U+3000)の四角記号の左側が欠けて表示される問題は、こちらでは既に修正しました。次に公開されるバージョンでは修正されています。

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

    返信先: 16TBファイルの対応について #32067
    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    (質問1)
    こちらのリンク
    https://jp.emeditor.com/text-editor-features/large-file-support/files-up-to-248gb/
    にある画面図の通り、15.9 TB、17,592,101 行の ASCII ファイルを処理するのに、83,190.860秒かかりました。使用したPCは、確かWindows 10 (64-bit)、Core i9-9900K、64GB RAM、2TB SSDだったと思います。ファイルが保存されているディスクは、Western Digital の 18TB ハード ドライブ (WD181KRYZ) です。

    (質問2)
    ファイルのサイズよりも、行数が重要になります。つまり、1行あたり1000文字のファイルよりも、1行あたり10文字のファイルの方が、より多くのメモリを必要とします。ファイルを開くことに失敗する場合は、仮想メモリを増やす必要があります。仮想メモリの増やし方については、こちら
    https://jp.emeditor.com/increase-virtual-memory/
    を参考にしてください。デフォルトの設定の通り、「ディスクベースを有効にする」がオンになっていれば、ファイルを開くだけで編集が不要な場合、一時ファイルの作成は必要ないはずです。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    既に、こちらでは修正いたしました。次に公開されるバージョンでは修正されています。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    こちらでも問題が再現しましたので、既に、こちらでは修正いたしました。次に公開されるバージョンでは修正されています。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    ご指摘いただいた動作についてですが、これは不具合ではありません。私のブログで以下のように説明しています。

    「v23.1 では、メモリに関連するアルゴリズムを見直し、より効率的な動作を実現しました。さらに、仮想メモリが不足すると一時ファイルを使用してデータを保存するようにしました。これにより、仮想メモリのサイズに気を遣わずとも、メモリ不足によるクラッシュの頻度を大幅に軽減することができました。このメモリ関連の改善の効果と、マルチスレッド、SIMD 命令セットの使用により、CSV を含む巨大ファイルの編集時に多くのコマンドで、v23.0 に比べて 1.51 から 41.2 倍に高速化しました。」

    https://jp.emeditor.com/emeditor-core/emeditor-v23-1-0-%e3%82%92%e5%85%ac%e9%96%8b%e3%81%97%e3%81%be%e3%81%97%e3%81%9f-%e3%83%86%e3%82%af%e3%83%8b%e3%82%ab%e3%83%ab-%e3%83%ac%e3%83%93%e3%83%a5%e3%83%bc%e3%82%92%e5%90%ab%e3%82%80/

    ストレージの残り容量がほとんどない場合には、一時ファイルを作成せずに警告メッセージを表示し、ファイルのオープンを中止する仕様になっています。ファイルを閉じたりEmEditorを終了すると、これらの一時ファイルは自動的に削除されます。EmEditorのプロセスが強制終了した場合でも一時ファイルは削除されます。Windowsの動作が不安定になったり、BSODの心配はありません。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております、江村です。

    先ほど、SSL証明書を更新し、問題を解決いたしました。この度はご迷惑をおかけして申し訳ございませんでした。

    今後ともどうぞよろしくお願いいたします。

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    ご連絡ありがとうございます。ただいまお調べしていますので、しばらくお待ちください。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    わかりました。次のバージョンでご指摘の部分、追加しておきます。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    次のバージョンでは元に戻します。

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

    返信先: IPアドレスのポップアップのリンク切れ #32032
    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    修正しておきます。ご報告ありがとうございます。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    バージョン24.4から、改行を含む行削除などを行った後に元に戻す際、フィルターが解除されるように変更しました。詳細を書くと長くなりますが、これは整合性の問題を避けるためです。例えば、文書全体をCtrl+Aで選択して削除し、元に戻す場合、フィルター中にも関わらず非表示になるはずの行が表示されてしまいます。このような整合性の問題を回避するため、元に戻す際には基本的にフィルターを解除するべきだと判断しました。ただし、改行を含まない軽微な編集の場合は、便宜上フィルターを解除していません。元に戻した後、必要に応じてフィルターを再設定してください。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    1. 元に戻す
    2. ワークスペース

    この2つは、まったく異なる問題です。

    1. 元に戻す

    編集を長時間続けて保存しない場合、元に戻すための情報が増えたり、編集に必要なメモリ領域が使われたりするため、元に戻すためのメモリが不足し、元に戻せなくなることがあります。保存を行うと、それまでの編集内容がすべて保存され、メモリがクリアされるため、再び元に戻すことが可能になります。したがって、編集中でもなるべく頻繁に保存することをおすすめします。

    2. ワークスペース

    [カスタマイズ] ダイアログの [ワークスペース] ページの設定を確認してください。[一時ファイルを現在使用しているファイルを含めない] がチェックされていると、巨大ファイルは保存されません。[次の行数を超えるファイルを含めない] で指定した行数を超えるファイルも保存されません。

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

    Yutaka Emura
    キーマスター

    いつもお世話になっております。江村です。

    このチェックボックスを外した後、最大メモリサイズをより大きな値に設定しないと効果がありません。例えば、最大メモリサイズを「300000」MBに変更してみて、何か変化があるかお試しいただければ幸いです。

    セル選択モードを解除するには、「並べ替え」ツールバーの一番左のボタンをクリックするか、[CSV] メニューの [セル選択モード] を選択してください。

    > 編集は、1文字挿入しただけでも「元に戻す」が効きません。

    ということですが、セル選択モードで、セルが1つだけ選択された状態で、F2 などを押して、その1つのセルだけに文字を挿入されたという意味でしょうか?

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

1 件の投稿を表示中 (合計 4,768 個)