別ペインの範囲を維持したまま、同範囲を編集したいというようなのはまた別の機能では?確かに、従来のウィンドウ分割の機能を流用する方向で考えていくと壁に当たってしまいますので、別機能としてゼロから開発するべきものなのかもしれません。それよりはキャレット(カーソル)のズレがない方がメリットかと。問題はそこなんですよね。妥協してしまった部分ですが、動作速度的に実用レベルになれば対応したいとは考えています。逐次処理だけで済まないでしょうか。技術的な話になってしまいますが...単純なテキストファイルでキャレット位置が、ファイルの先頭からの位置のみを保持している場合はそれで問題ないと思いますが、テキストエディターの場合はそうもいかなくて。常に再計算が必要なんです。この座標計算は編集が発生した箇所を基準にしてなるべく少ない計算で済むように工夫はしていますが、それでも負荷は無視できないレベルです。(マルチカーソルを使うとさらに負荷は数倍になります)この負荷が、別窓を開いているだけで、選択範囲もない状態なのに文字を入力・削除するたびに必ず発生することになるわけなので、そんなに必要とされていない機能であれば、同期しないほうが快適なのになぁと思う感じですね。どのエディターでもマウスでペイン移動すると、選択範囲やカーソル位置は解除されてしまいますね。大量の改行を追加した後、後方参照してるのが画面から流れてしまってもスクロールして見つけやすい?かも?なるほど。そもそもウィンドウ分割の機能自体を使っていなかったので参考にさせていただきたいと思います。常に再計算が必要なんです。単純にしか考えられないから色々見逃してしまいます。改行ストリームも自動折り返し機能が付くと中で更にサブストリームを用意すればいいのか?と混乱して、こういうのも実際に作ってない自分だとどうXY描画座標(2次元)を算出すればいいか、ストリームを表す1次元座標範囲の生成タイミングとか再計算フローとか思いつかないですし。この座標計算は編集が発生した箇所を基準にしてなるべく少ない計算で済むように工夫はしていますが、それでも負荷は無視できないレベルです。この負荷が、別窓を開いているだけで、選択範囲もない状態なのに文字を入力・削除するたびに必ず発生することになるわけなので、そんなに必要とされていない機能であれば、同期しないほうが快適なのになぁと思う感じですね。別窓なんだから描画放棄して、もういっそタスクとしてスタックできてタイマーとかカーソル移動とか限定した操作タイミングまで描画系計算だけでもほっとければいいんでしょうけどね、そんなふわっとしたこと言ってもしょうがない。シンプルエディタは応答性がなんぼですしね。別窓なんだから描画放棄して、もういっそタスクとしてスタックできてタイマーとかカーソル移動とか限定した操作タイミングまで描画系計算だけでもほっとければいいんでしょうけどね、そんなふわっとしたこと言ってもしょうがない。理にかなっていると思います。秀〇エディタさんはまさにその方式を採用されているようで、別窓のリアルタイム描画は放棄していて、フォーカスが別窓に移ったタイミングで再描画される感じになってますね。テキストエディターという性質上、動作速度を最優先したいという気持ちはありつつも、負荷にならない範囲でコードエディターのように重い機能をいかに軽く実装できるかという興味もありますので、どこまできっちり実装するかは難しいところですね。こちらは現象を再現することができませんでした。再現手順がわかりましたら教えていただけますと、改めて調査してみたいと思います。保存後、編集していないのに読み直しダイアログが出たので、ファイルを確認してみました。すると、ファイルの更新日時よりアクセス日時が新しかった場合に、読み直し判定が出ているんだと思います。うちの環境はBGでクラウド同期を行っているから発生したんだと思います。以前のバージョンでは出た例しがないので、謎です。返信ご報告ありがとうございます。強制的にファイルのアクセス日時のみ更新してみても、再現されませんでした。以前ですとファイルを開くだけでも更新されていましたから、もしアクセス日時のみで判定がされていた場合は検証段階で気づくと思いますし...。アクセス日時のみ更新コマンドは以下のとおりです。以前のバージョンでは出た例しがないので、謎です。ファイルの更新日時チェックにおける処理は以前のバージョンから変更していません。クラウド同期をご利用とのことですので、何らかのタイミングで同期が走ってファイルの更新日時が一時的に新しいものになり、その後、同期が完了して更新日時が元に戻るといった動作は考えられますね。実行し、その後、普通にテキスト編集をしているつもりでも、裏ではクラウド同期が走っています。回線の速度によってはクラウド同期に数分かかった場合など、同期が完了してからローカルに保存してあるファイルの更新日時がアップデートされるまでにタイムラグが発生しますので、更新したつもりがないタイミングでファイルの更新チェックにひっかかるといったことは考えられます。分割していないときは平和そのものなのに、分割した途端に時々発生するんですよね。返信ファイルの更新チェックはタイマーではなく、タブの切り替えやペインの移動など、エディターのフォーカス状態が変化したタイミングで行われます。分割していない場合は発生せず、分割した場合に発生するのはペイン間での移動によってファイルの更新チェックが動作しているためだと思います。クラウド同期のソフトによって一時的にファイルの更新日時が変更されることがあるのなら、たまたまそのタイミングでペインの移動を行ってファイルの更新チェックにひっかかってしまったというのは考えられますね。いった場合は、「外部でファイルが変更されています。押すと、そのファイルを閉じるまでは更新チェックをオフにできますので、対症療法ではありますがお試しくださいませ。ver3.2.0で確認しました。「変換中の文字列を挿入モードで入力」ONや、マルチカーソルでの入力や削除も改行でも正常に別ペインのカーソル位置、マルチでの範囲混合等も維持できてると思います。貧弱PCだけどでかいファイル編集もしてないし、詳しくないのでよく分からないですがパフォーマンスについて気になるとかはないです。動作確認のご協力ありがとうございます。うまく動いているとのことで安心しました。正常に別ペインのカーソル位置、マルチでの範囲混合等も維持できてると思います。上記の部分につきまして、実は、どうしても対応できなかった部分があります。オンで、別ペイン側に選択範囲がある状態にしておき、もう一方のペイン側でその選択範囲の内側にあたる部分を編集した場合、別ペイン側の選択範囲は解除されてしまいます。現在の仕様ではこの部分の実装が非常に難しいため、仕様上の制限事項ということでご容赦いただければと思います。返信その点のチェックし忘れてましたwやってみると履歴の巻戻し時変化した範囲がどこまで復元するかなどもありますね。編集中の範囲を別ペインで別に編集するというのは利用場面が思いつかないのでいいのではないでしょうか。カーソル位置もその行から離れることなく維持されるので、機能の目的は果たしてるのでは?「変換中の文字列を~」もどちらかといえば物書き向け機能だと思ってて、それなら複雑なのとも関係しないかと。IMEと描画連携難しそう。返信ご確認いただきありがとうございます。操作については、できるだけ選択範囲は維持するようにしましたが、ペインごとの編集履歴までは実装できませんでした。編集中の範囲を別ペインで別に編集するというのは利用場面が思いつかないのでいいのではないでしょうか。「変換中の文字列を~」もどちらかといえば物書き向け機能だと思ってて、それなら複雑なのとも関係しないかと。IMEと描画連携難しそう。機能は非常に厄介ですね。できてしまうので困ったものです。^^;機能を知る目的でデバッグ的に試行してれば、そう思う可能性は充分にありますねwしかし、普通に使ってればあまり見かける場面ではないかと。機能は非常に厄介ですね。できてしまうので困ったものです。入力してて非常に気持ちのいい機能なので普通に常用させてもらってますねw(ありがたや~コードは基本半角英数で、IMEの使用はコメントやデータなので、マルチカーソル含め複雑な場面はほぼないですね。