再現しました。

複数行に折り返されたレイアウト行のうち、先頭と末尾のレイアウト行を除いた中間のレイアウト行数分だけカウントが少ないようです。

GetLengthWithoutEOL() を GetLengthWithEOL() - 1 に置換した影響かと>354033d#diff-8038a8583a5548b60ab7e451ea17113e

レイアウト行は改行文字で終端しないことがありますから、無条件に -1 すれば実際より目減りします。

GetLengthWithoutEOL() を GetLengthWithEOL() - 1 に置換した影響かと

お見事、それ多分正解。
201桁選択中で、6個の行末が含まれている。
文字はすべて全角だから95字であってそう。

さて、どう直したものか。

LenWithEOL にすると CRLF が⒈文字になります(非互換)。元の通り LenWithoutEOL + EOLLen なら CRLF は２文字です。

PRを辿ってみました。
#993 責任者ぼくですね...orz

元ネタは高速化のために色々変えてるわけですが、方向性がおかしかったかというとそうでもないと思っています。GetLineStrが効率悪い感じなのはきっとそうなわけで。

どうしたらいいか。

思い付く感じでは、選択の始点（行・桁）と選択の終点（行・桁）を物理位置（行・オフセット）に変換して、一連のUNICODE文字列を取得してから一括でバイトシーケンスに変換してバイト数を求めたら速いんじゃないかな、とか。

ま、ＰＲは、みんなでレビューしてるので共同責任ってことで、どうするかに集中しましょ(笑)
そのためのチームやしｗ

対処療法、選択範囲（行）の中に画面橋折り返し改行が何個あるか数えて足す。。。ああダメな直し方の予感ｗ

内部実装わかってないのでどうすれば早いかには全然貢献できそうにないですが、
改行文字のカウントとかもあるので慎重にって感じですね。

自分で書いといてスルーしてましたが、変なトコもう1つありました。

201桁選択中で、6個の行末が含まれている。
文字はすべて全角だから95字であってそう。

全角100文字を選択してるのに 201桁 とは、これ如何に。

桁＝半角1個分を1とする幅の単位。全角は2桁になる。

全角100文字を桁数に換算した場合の期待値は200桁なので、ここもおかしいっす。

文字数カウントの話ですからキャレット位置は無関係です。

100文字選択しているのに「95 chars」。消えた５文字は全７レイアウト行のうち先頭と末尾の２レイアウト行を除いた５レイアウト行から、改行文字(※存在しない)の分として無条件に引かれた -1 × 5 です。

お、これ自分が入れてしまった不具合ですね。直さないと…。

#1241 が merge されて問題が解消したと思うので close します。