TEditorを使っていた真魚1.xxでの仕様は、元のテキストがどの改行を使っていても、
読み込んだ時点でCRLFにしてしまって、EUCで保存するときのみLF統一で、
それ以外の文字コードではCRLFで保存しちゃうということで、
WindowsのエディタなんだからWindows風の処理をするのは当たり前で、
唯一Windows以外で使うことがはっきりしているEUCでのみ、ケアしてあげる方法にしてた。
バージョン2.xxでは、どの改行コードだろうが、混在していようが、
全部そのまま読み込んで、画面には区別したマークで表示し、
そのまま保存するような仕様になっている。

自由自在ってのは良いことなんだけれど、結局問題になるのは正規表現である。
記事：CRとLFの問題
サクラと同様、改行コードの混在が出来る仕様では、
正規表現を使う側もそれを意識して、￥rと￥nを使い分ける必要があり、
萌ディタ作者みたいに、改行は￥nだと思いこんでいる人にとっては、
普通に検索したつもりでいるのに、わけわからない検索結果になることがある。
そこで、真魚が持つデータを、正規表現エンジンに渡す際だけ、
CRLFをLFに変換とかしてあげれば、ちゃんとつじつまの合う結果が得られるわけだけど、
それだとせっかくの真魚のデータ構造の利点が台無しになってしまうのだ。
検索の時にメモリを確保する必要がないってうことを優先した作りなので、
検索をさせるたびにそういった作業を行うのは非常にまずい。

さて、解決策として、これももうやろうと言うことで意思は固まったのだが、
内部データを全てLFのみで扱い、保存やコピペやD＆Dの時だけ適宜変換する。
これで何も考えなくても正規表現は￥nで通るようになる。
初心者が正規表現を使うと言うことはないかも知れないが、
正規表現は知っているけど改行コードの話は知らないっていう人が迷わなくなる。
デメリットは改行コードが混在するテキストを扱えなくなることなので躊躇したが、
混在するテキストを混在のまま扱うことが果たしてメリットかどうかと。

メモ帳はCRLFのみを改行として扱い、個別に出てきたCRもLFも不可視記号扱いし、
この仕様だと当然、LFのみやCRのみの文書は一切の改行を含まない事になるが、
そのまま保存してもCRやLFを記号として保存するのでデータは壊れない。
すばらしいやり方だと思うが、EUC対応エディタでそれだと不便すぎる。

ともかく、コレでまた内部で大きな仕様変更をすることになるので、
またしばらく動作確認を慎重にやって行かなきゃならなくなる。

ついでに。挿入/上書きモードについて。
間違って押したInsキーで上書きモードに切り替わると本当に腹立つし、
他に押す理由がないので、アロンアルファかツリロンアルファで固めちゃいたいってくらい、
上書きモードが嫌いなので、ぎょえ（仮）の時点から上書きモード非対応で来たのだが、
メモ帳ってInsキー押しても挿入モードのままなのね。
別の方法で切り替わるのか、はじめから対応してないのか知らないけどさ。
邪魔にならないような方法での上書きモード実装を考えてはいるが、嫌いなので微妙。