フォーラムの返信を作成しました。
-
投稿
-
いつもお世話になっております。江村です。
さきほど公開した 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の問題というよりも、ディスクまたはメモリの不具合の可能性が考えられます。
よろしくお願いいたします。
いつもお世話になっております。江村です。
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 コマンドなどで、ディスクに問題がないか確認してみてください。
どうぞよろしくお願いいたします。
いつもお世話になっております。江村です。
「どうして、yasuji様は、そのように感じられるのでしょうか?」については、下記の通りです。
１．過去の検索（置換）ウィンドウの切替キー操作時の不具合についてのメールでのやり取りの「#31387 – 〔要回答〕報告済：検索（置換）ウィンドウの動作不具合」において、ユーザのお好みの動作が異なるという理由と、この方法で代替できますよというご説明で修正をお断りされました（実際に修正いただいたのは、このメールの内容をトピック作成した後でした）。私個人としては、他のテキストエディターができていることで、無理を言っているつもりはなく、このような説明で修正を拒絶されたと受け止めて、かなりショックでした。yasuji様のお気持ちは理解しました。私の返信メールが言葉足らずで、お客様のお気持ちに寄り添えていなかったと思います。不快な思いをさせてしまい、申し訳ありませんでした。しかし、yasuji様のご要望を拒絶しているわけではありませんでした。私は、一言も「できない」とは書いていません。「これは、ユーザーによって好みの動作が異なると思います。」と書いただけで、「できる」とも「できない」とも書いていません。どうして、私の返信メール1件だけで、要望が拒絶されたと感じられるのでしょうか?
私は、毎日、多くのお客様からご質問やご要望のメールを受信しています。お客様のご要望については、まずその内容をできるだけ正確に把握する必要があります。1件のメールだけでご要望を把握することは難しく、その後、返信メールを重ねて議論を行い、ご要望にお応えする形になります。1件のメールだけで、すぐに「できる」か「できない」かを判断することは、ほとんどありません。お客様から返信メールをいただかない場合には、そこで議論は終了してしまい、ご要望にお応えすることができなくなってしまいます。
したがって、私の返信メールは、yasuji様のご要望の内容を確認するために書かせていただいたものであり、拒絶したものではありません。具体的には、
「例えば、検索ダイアログが表示されている状態で、再び Ctrl+F を押した場合には、どうするのかとか、検索ダイアログで [置換 >>] ボタンを押した場合、さらに 検索ダイアログにフォーカスが設定されている状態で Ctrl+H を押した場合など検討しなければなりません。」
の内容について、yasuji様のご意見をお聞かせいただきたかったのです。yasuji様のご意見を聞かずに、ご要望を実装することは難しいと思うからです。
私がyasuji様にお願いすることは、私のたった1件のメールだけで、拒絶されたとか否定的に思わないでいただきたいのです。私が言葉足らずだったり、配慮が足りなかったのは認めます。申し訳ございませんでした。しかし、yasuji様も、これにめげずに、建設的な議論をしていただきたいと思っています。
２．「ここ最近のEmEditorのリリース情報について」のトピックにおいて、「不具合は非常に軽微なもの」としてご説明しておりましたが、追及した結果、その非常に軽微なものの中に２バージョンでクラッシュバグが合計５件も含まれていたことが判明し、かなりショックでした。
まず、バグの無いソフトウェアは存在しません。サンプルプログラムのような小さなアプリでしたら存在するかもしれませんが、市販されているような標準的なサイズのアプリの中では、どんなに優秀なソフトウェアにもバグは存在します。マイクロソフトが販売しているソフトウェアでも、Windowsは月に数回の更新を行っていますし、私が使用しているVisual Studioも月に数回、更新されていますが、それほど騒ぐほどの問題ではないと思います。EmEditorは、ユーザーからのご指摘やクラッシュレポートをいただいたら、すぐに対応して修正しています。履歴に不具合修正の項目が多いから、不安定ではないかと不安をお持ちになるかもしれませんが、実際にはその逆で、不具合を修正しないで更新がないソフトウェアの方が不具合が多いこともあります。
また、クラッシュが致命的な不具合だと感じていらっしゃるかもしれませんが、私は必ずしもそうは思っていません。技術的には、クラッシュをさせないで無視して継続することも可能で、そうしているソフトウェアも存在します。しかし、EmEditorでは、不具合を意図的にクラッシュさせて、お客様にクラッシュレポートをフィードバックしていただくことにより、私がすぐに修正して更新するという良い循環を実現しています。そのため、他のソフトウェアよりもクラッシュが多く存在するように見えるかもしれませんが、ソフトウェアの品質は向上しています。
私が「不具合は非常に軽微なもの」として説明したのは、非常に稀な条件のもとで発生する不具合のためです。既定の設定で、普通に行う動作ではまず発生することのないような不具合のため、非常に軽微なものと表現いたしました。しかし、この点についても私の言葉足らずであったことを認めます。申し訳ございませんでした。今後は、不具合の内容をできるだけ丁寧に説明いたしますので、お許しください。
以上、何かと懐疑的な気持ちをお持ちのこととは存じ上げますが、今後もご要望に対して拒絶することはありませんので、これに懲りずに、EmEditorをご愛用いただきますようお願い申し上げます。
最後に、私も人間ですので、今までのような攻撃的な発言が続いてしまうと、私もサポートする気がなくなってしまいます。このフォーラムは、ユーザー間の交流の場であり、私との1対1のサポートの場ではございません。フォーラムでのご質問やご意見に対して、必ずしも私からの返信が付くとは限らないことをご了承願います。また、過去のメールでのやりとりの内容をフォーラムに転載される場合は、事前に私の許可を取っていただきたかったと思います。勝手にメール内容が転載された点について、私も不快な気持ちになりました。攻撃的な内容の場合には、私のことはともかく、他のユーザーの方々へのご迷惑にもなりますので、フォーラムではなく、直接メールでいただいた方がありがたいです。その点、ご理解いただけると幸いです。
よろしくお願いいたします。
いつもお世話になっております。江村です。
「また、ファイルを開くだけで編集しない場合は、一時フォルダの空き容量は不要です。」が、正しいというならば「〔致命的バグ〕メモリ不足でもファイル読込を停止しない」の事象はどのように考えた良いでしょうか？
この事象は、私が[ディスクベースを有効にする(B)]をOFFに設定したことが悪かったということでしょうか。私が先に説明した内容は、ディスクベースが有効になっている既定の設定を前提としていました。設定を変更されている場合は、最初にそのことをお知らせいただければと思います。ディスクベースが無効の場合、一時ファイルを保存するためのディスクの空き容量が必要です。また、ディスクベースが無効になっていると、数GB以上の大きなファイルを開くのはほぼ不可能です。巨大ファイルを扱う場合は、既定の設定の通り、ディスクベースを有効のままでお使いください。
（Ｑ１）
物理メモリではなく仮想メモリ内で使用できるヒープメモリとなります。ただし、この設定がすべてのケースで反映されるわけではありません。特に、ファイルを開く際に必要な特定のメモリは、指定したサイズよりも大きくなることがあります。（Ｑ２）
仮想メモリのサイズに依存するため、私からは「できる」や「できない」とは断定できません。お客様ご自身でご確認いただければ幸いです。もしできない場合は、仮想メモリのサイズを増やしてPCを再起動することで、解決する可能性がありますので、お試しください。よろしくお願いいたします。
Japelin様
いつもお世話になっております。江村です。
なんでそんなに攻撃的な投稿が多いのでしょうか。
仕様に関する疑問が出ることはわかりますが、正直、ユーザーとして適切な範囲のリクエストなのか疑問ですご意見ありがとうございます。私とyasuji様とのやり取りが他のユーザーの皆様にも不快な思いをさせてしまい、申し訳ありませんでした。正直なところ、私のサポートにも限界を感じており、他のユーザーの方のご意見をいただけて良かったです。今後もご支援いただければ幸いです。
引き続きよろしくお願いいたします。
いつもお世話になっております。江村です。
誠意を持ってお答えしているつもりですが、残念ながら、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ページをご覧ください。
このように、大きなメモリーを必要とするアプリでは、あらかじめページングファイルの初期値を大きく設定しておく必要があります。私はこれをOSの問題と考えています。
HPに記載されている「16 TBまでのファイル」の宣伝は、EmEditorのカタログスペックの見栄えを良くするためだけの機能だと理解しました（8GB～32GBのRAMを搭載した一般的なPCでは開けないというご回答のため）。
宣伝と思われるかもしれませんが、事実を記載しており、誇張ではありません。「メモリの許す限り」との注記もあります。事実を伝えないとユーザーに正しい仕様が伝わりません。EmEditorの仕様や機能をWebサイトに明記することが重要だと考えています。「8GB～32GBのRAMを搭載した一般的なPC」という指摘はその通りですが、EmEditorユーザーの中には64GB以上、さらには256GB以上のRAMを搭載したPCをお持ちの方も多くいらっしゃいます。EmEditorは、ユーザーの要望に応じて巨大ファイルを扱えるように長年改良を重ねてきました。これは決して「カタログスペックの見栄えを良くするためだけの機能」ではなく、多くのユーザーがこの機能を求めてEmEditorを選んでくださっています。
よろしくお願いいたします。
いつもお世話になっております。江村です。
修正を拒絶する理由は、修正工数が大きすぎてかつ複雑なため、やりたくないからでしょうか？
そのようなことは思っていません。修正を拒絶することはありません。どうして、yasuji様は、そのように感じられるのでしょうか? もし、私の書き方が、yasuji様に、そのような印象を与えてしまったのでしたら申し訳ありませんでした。
先ほど公開した v24.4.902 にて修正いたしました。
よろしくお願いいたします。
いつもお世話になっております。江村です。
（Ｑ１）
ご指摘の通りです。（Ｑ２）
その通りです。（Ｑ３）
500行ごとに進捗を更新するように最適化しています。不具合ではありません。（Ｑ４）
検索用スレッド数が[スレッド数(N)]が1の場合、内部ではその値に1を足して2スレッドで検索しているのではないかというご質問ですが、これは考えられません。よろしくお願いいたします。
いつもお世話になっております。江村です。
> 答えていただきたい回答になっていません。
誠意を持ってお答えしたつもりでしたが、yasuji様のご期待に沿えず申し訳ありません。先に述べたように、64GB RAMのPCで動作確認を行いました。そのため、一般的なデスクトップPCに搭載されている32GBのメモリでも動作する可能性はあります。ただし、さまざまな条件があるため、必ずしも動作するとは限りません。メモリは多いに越したことはありませんし、8GBでは難しいかもしれません。また、これは物理メモリではなく仮想メモリに影響しますので、少ないメモリでも仮想メモリを大きくすることで動作する可能性が高まります。
よろしくお願いいたします。
いつもお世話になっております。江村です。
これは、使用されているフォントのデザインの問題です。設定のプロパティの [表示] ページの [行間] で調節可能です。ここには -1 のように負の値を入力することもできます。ただし、行頭の全角空白（U+3000）の四角記号の左側が欠けて表示される問題は、こちらでは既に修正しました。次に公開されるバージョンでは修正されています。
よろしくお願いいたします。
いつもお世話になっております。江村です。
（質問1）
こちらのリンク
/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文字のファイルの方が、より多くのメモリを必要とします。ファイルを開くことに失敗する場合は、仮想メモリを増やす必要があります。仮想メモリの増やし方については、こちら
/increase-virtual-memory/
を参考にしてください。デフォルトの設定の通り、「ディスクベースを有効にする」がオンになっていれば、ファイルを開くだけで編集が不要な場合、一時ファイルの作成は必要ないはずです。よろしくお願いいたします。
