フォーラムの返信を作成しました。
- 投稿
興味深いバグですね。いろいろ実験してみたところ・・・
改行で終わっている行に関して，濁点・半濁点のついた片仮名の字数分だけ文字列の末尾が消える，という現象のようです。
濁点・半濁点のついた片仮名は，全角→半角変換に伴って字数が倍に増えますが，そのぶん文字列のバッファーをはみ出した末尾が消えてしまっている，というような印象です。
（追記：投稿後に江村さんが既に返信されていることに気づきました。失礼しました）詳しいご説明ありがとうございます。「最大値」設定の必要性がよく分かりました。
既定値はいくらくらいがいいのでしょうね。
私の場合，プログラムで生成する，RFC4180 的に正しい CSV を扱うことがほとんどなので，ほとんどの場合，上限は無くていいのですが，一般には不正な引用符はありえますもんね。
私の仕事の範囲だと，セル内に改行が 1 万もある可能性は考えにくいです。1000 くらいなら（今のところ遭遇してないと思いますが）ありえます。セルツールバーの件は，あとでもう一度調べて，問題があるようなら改めて別のトピックを立てたいと思います。
EmEditor 以外ではこのような現象は今のところ見つかっていないんです。Atom もメモ帳も Skype も LibreOffice も Edge も Firefox も Thunderbird も正常です。
主に Windows 側に問題があるとしても，EmEditor との組み合わせで問題が発生する，という可能性はないでしょうか。なお，#24896 に書きましたように，Windows 10 です。古い Windows ではありません。
また，フォントはさまざまに変えて試していますが，正しく表示できるフォントが一つも見つかっていません。
残るは DirectWrite ですが，これをオンにする方法，というのが調べても分かりませんでした。どうすればよろしいでしょうか。これとよく似た現象を見つけたので報告します。
こんどは合成用濁点ではなく，欧文に使う合成用ダイアクリティカルマークです。U+0061 U+006F U+0302 U+0065 という文字列を表示します。
つまり，「aoe」の「o」と「e」の間に合成用のサーカムフレックスを入れます。すると，本来なら「aôe」のように見えるはずです。
ところが，Source Code Pro や Consolas では「aoê」のように，サーカムフレックスが「e」の上に付いたように表示されます。この「a」を他の文字に変えると，例えば「c」に変えると，正常に「côe」と表示されます。
いろんな文字で試すと，異常なのは「abefijkopqruvwxzAEFKOQRUVWXZ」を使ったときで，それ以外のアルファベットだと正常です。また，いくつか試した記号や（英字以外の）文字では正常でした。
フォントをいろいろ変えてみると，異常な場合の表示のされ方が少し違うものの，異常の起こり方は（試した範囲では）同じでした。
Source Han Code JP N や Inconsolata では，異常な場合のみサーカムフレックスがバッテンマークになります。
Georgia や游ゴシックでは，異常な場合のみ，サーカムフレックスが合成されずに独立の文字として表示されます。
Linux Libertine G では，異常な場合のみサーカムフレックスが消えます。U+0061 U+006F U+0302 U+0065 が正常に表示されるフォントは，試した範囲では一つもありませんでした。
OS は Windows 10 Pro（バージョン 1803，ビルド 17134.165），64 bit OS です。
EmEditor は 17.9.0（64 bit）です。表示などの改善ありがとうございます。
> あまり多くのオプションを追加するよりは、マクロやスニペットを使用して自由にカスタマイズすることが現実的ではないかと思います。
オプションをやたらに増やさないほうがよい，という話は非常によく理解できます。
ただ，今の場合，オプションを導入しないと，組込みの機能が正常に働かない，という話なので・・・そこで，もう少し他の言語についての情報提供です。
いわゆる「オフサイドルール」（インデントの階層でブロックの入れ子関係を表現する構文）を採用している言語の例です。
コメント記号のインデントレベルに制約があります。
いくつか例を挙げます。◎Python
複数行コメントは，先頭行の前と最終行のあとに"""の行を置きます。よって現行仕様では正しいコメントになりません。
この点では Ruby と似ていますが，Ruby は=begin/=endを行頭に置かなければならないのに対し，Python ではブロックのインデントに合わせて"""もインデントしなければなりせん。正しくインデントしないとエラーになります。単行コメント（先頭に
#を付ける）の場合，インデントはどうでもいいみたいです。◎CoffeeScript
複数行コメントは，先頭行の前と最終行のあとに###の行を置きます。よって現行仕様では正しいコメントになりません。
Python と違うのは，###のインデントがどうでもいいことです。単行コメント（先頭に
#を付ける）の場合も，インデントはどうでもいいみたいです。◎Slim および Sass
以下に関しては，Slim と Sass はルールが同じなので，まとめて書きます。単行コメントはインデントしなければなりません。正しくインデントしないとエラーになります。
複数行を囲むインデント形式はありません。
ただ，単行のコメントの直後に，それよりもインデント階層の深い部分があるとそこまで含めてコメントになります。
そこが Python や CoffeeScript と違うところですね。ところで，「マクロやスニペットを使用して自由にカスタマイズ」というのは，コメント化，非コメント化を，組込みの機能ではなくマクロやスニペットで実現する，という話でしょうか。
マクロは分かるのですが，スニペットでもそういうことができるのですか？ああ，この投稿欄は行頭スペースが削除されるんでしたね。
最後の三つのコード例が意味不明になっちゃいました。
スペースを「␣」にして再掲します。★ここから
例えば
3.times␣do␣|i|
␣␣puts␣i
endの第 2 行をコメント化した場合は
3.times␣do␣|i|
#␣␣␣puts␣i
endではなく
3.times␣do␣|i|
␣␣#␣puts␣i
endにしてほしい，ということです。
コメント化／非コメント化のショートカットがあるとは知りませんでした。
少し不便なのが，①二段階であること，②コメント化と非コメント化でショートカットが違うこと，ですが，現状でもかなりありがたい機能です。
質問です。
Ctrl + K, C および Ctrl + K, U は，［編集］→［選択範囲の変換］→［コメント挿入］／［コメント削除］と同じものでしょうか。
であれば，メニューの横にショートカットも表示していただけないでしょうか。ところで，「コメント挿入」「コメント削除」は適切な表現でないように思います。
というのは，これは選択したものをコメント化するのであって，そこにコメントを挿入するわけではないし，コメント記号を取り除いて非コメント化するのであって，コメント自体を削除してしまうわけではないからです。
「コメント化」「非コメント化」ではダメでしょうか。次に要望です。
Ruby で，範囲選択した状態でコメント化すると，選択範囲の先頭・末尾にそれぞれ「=begin」「=end」が挿入されます。
これは，Ruby のプロパティーの「強調(2)」の「コメント」の「開始」「終了」の値をそのまま入れているのだと思います。
しかし，Ruby の =begin/=end は，C などの「/*」「*/」などとは違って，行中に使うことができません。=begin
x = 3
=endのように，「=begin」だけの行と「=end」だけの行で囲まなくてはならないのです。
（正確に言うと，「=begin hoge」のようにスペースなどを挟んで何かを書くことはできます。しかし「=」の前にはスペースも置けません）よって，Ruby の場合，選択範囲の先頭行の前に「=begin」の行を挿入し，選択範囲の最終行の後に「=end」の行を挿入してほしいです。
もっとも，Ruby の =begin/=end はコーディング規約で避けられることが多いうえ，本来は一時的にコードをコメント化するためのものではなく，コード中に機械処理可能なフォーマットのドキュメントを埋め込むためのものです。
なので，範囲選択の場合でも =begin/=end のコメントではなく「#」のコメントにしてほしいですが。それから，Ruby の「#」や C の「//」のような行コメントについて。
現状では，コメント記号しか入れてくれませんが，コメント記号のあとにスペースを一つ入れてほしいんです。
それがふつうの（？）書き方だからです。
Atom のコメント機能はそうなっています。
設定で切り替えるのでもかまいません。また，現状ではコメント記号を挿入する位置は行の先頭ですが，これをインデント位置に変えてほしいんです。
例えば3.times do |i|
puts i
endの第 2 行をコメント化した場合は
3.times do |i|
# puts i
endではなく
3.times do |i|
# puts i
endにしてほしい，ということです。
言語にもよるのでしょうが，少なくとも Ruby ではこれが望ましいスタイルとなっているようです。
たとえコメントでもインデントのコーディング規約に従うべき，ということでしょう。複数行が選択されていて，インデントのレベルが同じではない場合は，最もインデントの浅いものに合わせます。
Atom はそうなっています。
こちらも，設定で切り替えるのでかまいません。非常に細かい話ですみませんが，Ctrl + C でコピーしたテキストで，コードポイントのあとにスペースが付いています。
コードポイントのテキストを素早くコピペ利用するには，余計なスペースが無いほうがありがたいです。
もし簡単に直るようでしたら無しでお願いします。仕様ということでしょうか？
率直な感想を述べると，受け入れがたいです。まず，技術的にはその数え方は code unit を数えているのであって，文字を数えてはいません。
JavaScript の String.length も同じ動作ですが，これは文字数を表すプロパティーではなく，UTF-16 の code unit で測った長さを返す関数です。（よく「文字数を表す」と書いてありますが，それは解説のほうが間違っている）また，内部が UTF-16 なのは実装の都合であって，ユーザーにはあずかり知らぬことです。「メモリー上でこうなってるから 𩸽 や 𡈽 や 😀 を二文字と数えさせて」といわれても，多くのユーザーにはその意味するところさえ分からないのではないでしょうか。そして，具体的にどの文字がおかしな数え方になるかも分からないでしょう。
Microsoft Word も同じとのことですが，それは Word が異常なだけで，LibreOffice Writer はちゃんと文字数を表します。
Delフサさん，ご教示ありがとうございます。
カーソルの右のスペースは削除されるからそうなるのですね。
人によるのでしょうが [Home] や [End] は私にとっては押しづらく，また，[Home] を押し忘れてうっかり保存すると，もう一度保存操作をやっても保存が行われないので整形もされない，という点がちょっとツラいですが，提案が採用されなかった場合はこの方法で対処しようと思います。この変更はおおむね歓迎ですが，逆にありがたくないケースもあります。
最終行がインデントされたテキストを書き終わり，最後に [Enter] を押すとオートインデントによってスペースだけの行ができますが，この状態で保存した場合はやはりそのスペースは削除してほしい。
1～2 段のインデントなら [BackSpace] で消せばいいのですが，多段になるとつい [BackSpace] を押しすぎることもありますし，[Shift]+[Ctrl]+[←] とか [Shift]+[Home] とかで選択して削除とかも面倒です。[Ctrl]+[L] という手もありますが，クリップボードが変化するのは嬉しくありません。「最終行がインデントされたテキスト」は，Python，CoffeeScript，Slim，Sass などでよくあります。
そこで，beta 4 の仕様を基本にしつつ，カーソル行が最終行だった場合はやっぱり末尾空白を削除する，という仕様はいかがでしょうか。
なお，「EmEditor v17.2.0 beta 4 を公開しました 」において
> [行末の空白を削除] コマンドで、カーソル位置の右側の空白は削除しないようにしました。
とありますが「カーソル位置の右側の空白」は「カーソル行の行末の空白」の間違いですよね？
マクロファイルは見つかりました。
以下，ユーザー名を伏せ字で「USERNAME」としてご説明します。
自作のマクロファイルは
C:\Users\USERNAME\Documents\My Macros
に入っていました。
一方，「マクロのカスタマイズ」の「オプション」を見ると，「新しいマクロを保存または選択時、マイ マクロに追加する」にチェックが入っており，「フォルダ」が
C:\Documents and Settings\USERNAME\My Documents\My Macros
になっていました。
OS は Windows 10 なので，「Documents and Settings」があるはずありませんよね。
この Windows 10 は，Windows 7 からアップグレードしたものですが，アップしたのはかなり昔です。さて，上記ダイアログで「フォルダ」の下にある「リセット」ボタンを押すと，フォルダーのパスが
C:\Users\USERNAME\Documents\My Macros
に変わりました。
これにより，「マクロ」→「選択」で開かれるフォルダーが，この自作マクロを収めたフォルダーになりました。> どのバージョンから v17.0.2 に更新されたのでしょうか?
定かではありませんが，こまめに上げていたはずなので，恐らく v17.0.1 からだと思います。
> インストーラーがマクロを消すことは考えられないと思います。
ですよね。
> マクロ メニューの [カスタマイズ] の [マイ マクロ] の一覧で、お使いのマクロが存在するか確認していただけますでしょうか?
ここに表示されるのは以下の八つです。
Sum.jsee
ValidateXml.jsee
WrapTags.jsee
SymbolList.jsee
GotoDefiniton.jsee
PopBrowseContext.jsee
ParameterInfo.jsee
AutoCopy.jseeまた，ここに表示はされませんが，これらと同じ Macros フォルダーに「IPTip.jsee」というのも入っていました。（マクロは計九つ）。
いずれも私は書いた記憶が無いものです。
自作のマクロは，よく覚えていませんが，4～6 個あったと思います。
設定のエクスポートは，すぐには用意できませんが，のちほど。
まず，メニューについては，リセットはせずに，「メニューの変更」で対処しました。
さて，本題のほうですが，再現条件が分かりました。
「ツール」→「カスタマイズ」→「並べ替え」の設定によって，「重複行を削除」の動作が変わるようです。
「大文字、小文字を区別しない」が OFF だと空行が一つにまとまりますが，ON だとまとまりません。
また，「全角、半角を区別しない」が OFF だと文字を含む重複行がまとまりますが，ON だとまとまりません。Version 16.9.2 でしたが，今朝 Version 16.9.3 に上げて動作が変わらないことを確認しました。
ツールバーの
Abc
Abcアイコンを使っていたので，どのコマンドか意識していませんでしたが，[重複行の削除] のほうでした。
[重複行の削除/ブックマーク(高度)] の場合は，期待どおり空行が一つにまとまりました。
当面，実用上は「高度」のほうを使えば用が足りますが，私の環境で [重複行の削除] のほうの動作が意図と違うのであれば（急ぎませんが）解決しておきたいと思います。
ところで，これに関連して，コンテキストメニューだと「高度な操作」の中に [重複行の削除] と [重複行の削除/ブックマーク(高度)] がどちらもあるのですが，プルダウンメニューの「編集」→「高度な操作」には[重複行の削除/ブックマーク(高度)] がありません。
これはそういうものなのでしょうか？その後，改めてやってみたら，（とくに設定を変更したつもりは無いのに）現象が起きていたファイルでことごとく現象が起きなくなってしまいました。？？？？
そこで，今まで試してなかった拡張子のファイルをいろいろ試してみたところ，HTML ファイルで現象が再現しましたので，このファイルとレジストリーデータをメールにてお送りします。
よろしくお願いします。再現条件を探ろうといろいろやってみましたが，今のところよく分かりません。
以下のようなことが起こりました。
（具体的な設定名や拡張子名などが書いてない場合がありますが，きちんと記録をとっていなくて思い出せなかったものです）あるファイルで現象が起こることを確認。
同じ拡張子のいくつかのファイルを開いてみて，やはり現象が起こることを確認。
二つか三つの拡張子で確認しました。一方，別の拡張子のファイルで現象が起こらないケースを見つける。
その拡張子の別のファイルでも現象は起こらなかった。この時点で，「拡張子依存ではないか？ というか，拡張子ごとの設定の違いに依存するのでは？」と思われた。
現象が起こる拡張子と起こらない拡張子とで，「スクロールのプロパティ」などの設定の違っているところを探る。
たとえば，「スクロールオプション」の「水平罫線」とかが違っていた。そこで，現象が起こる拡張子の設定で，該当箇所の設定を変更してみる。
現象が起こらなくなった！
「お，やはりこの設定なのか？」と思って，設定を元に戻してみる。
「あれ，現象が起こらないまま（？？？）」もともと現象が起こっていなかった拡張子の設定を変更してみる。
「ん？ とくに変化はないぞ」ここでよく分からなくなる。
どうも，どこか特定の設定項目の設定値で現象の起こる／起こらないが変わる，というような単純なものではなさそう。同じ設定に関連づけられた拡張子は連動して変わるようなので，やはり拡張子というよりも設定に依存するぽい。
結局，「現象が起こる」から「現象が起こらない」に変わった拡張子については，いろいろやっても元には戻らなかった。
現象が起こる拡張子の設定で，「スクロール」を「リセット」したら現象が起こらなくなったケースもあった。
んー，なんだかよく分かりません。
たぶんそれと同根だと思いますが，Ctrl + マウスホイールでミニマップを縮小したときに，下のほうに縮小前のミニマップの画像が残ります。
ミニマップ領域の幅を変えるなどすると再描画されて不要部分が消えます。話に参加させてください。
異体字セレクターの無視は必須と思います。
改行コードの違いの無視もできるとありがたいですね。
よくあるのが，改行をまたぐ foo\nbar みたいので検索する際ファイルによって改行が LF でなく CR + LF だったりして，うまくいかないことが。平仮名／片仮名の同一視もあるといいのかもしれません。秀丸ではできるそうです。
Unicode 正規化によって同一となるものの同一視はぜひ。どの正規化形式にするのかは要検討ですが（一部の漢字で非常にややこしいことになるので）。
全角／半角の同一視については当然，片仮名にも適用してほしいのですが，「パス」と「ﾊﾟｽ」のように文字レベルでは対応が取れないものも拾えるとありがたいです。
秀丸では小書きの仮名（例：ぁ）と並字（例：あ）の同一視もできるそうです。
これらって，オプションで個別に ON/OFF できるようになるんですよね？
