返信

> > 私のほうはまったく意識していなかった部分だったので、「やべっ」と思いましたが、思ったよりも深刻な競合はなさそうで、結果的にラッキーでした ^^; > > そんな心境でしたか (笑 > 結果的にお互いラッキーだったようで何よりです。 > > > 「直接入力」や「削除」といった基本的な操作の場合、入力される文字がすべてのカーソルで共通になるため、上記の 1 ～ 3 のような処理手順は踏んでおらず、実質的にほぼ同時編集が可能な仕組みになっています。(つまり、スクロールや各カーソル位置での基点の更新は発生しません) > > > > 一方、「貼り付け」については、同じ文字列が貼り付けられるケースもありますが、複数の選択範囲をコピーして、それぞれに対応する文字列を貼り付けることも可能です。 > > > > このような仕様のため、「直接入力」のような同時編集の仕組みは使えず、実際には上から順にカーソル位置へ貼り付けていく、いわば「手動操作」を内部的にシミュレートすることで実現しています。 > > なるほど、「直接入力」などと「貼り付け」の質の違いがわかりました。 > > あまり意識してなかったのですが、コピー元とペースト先のカーソル数を同一にすると、それぞれに対応して貼り付けられますね。 > > それに伴った仕様の違いも把握いたしました。 > 詳しく教えていただきありがとうございます。 > > > そこで、挙動をできる限り「直接入力」に近づけるための新たな案として、「基点の更新を一時的に停止できるロック機構」を導入する方法を考えてみました。 > > > このロック機構を導入しておけば、今回は [貼り付け] のための対応ではありますが、今後、同様の問題が他のコマンドでも発生した場合に、より柔軟に対処できるようになるかと思います。 > > 新案、拝見しました。たくさん考えていただいてありがとうございます。 > 今後のためにもなっているのがいいですね。 > > ひとつ疑問があるのですが、[貼り付け] で実体カーソルの行が変わる場合はどうなるでしょうか。 > 例えば、コピー元に改行を含んでいて 101 行目に変わったり、折り返し表示で物理行が変わる場合です。 > > もしこれで基点が 100 行目のままならば、少し違和感が残ります。 > （現在の挙動と比較すると僅かなものですが） > > > 2. 基点更新をロック (このタイミングで、基点を実体カーソルの位置に更新) > > > > - ここから従来の処理 (ロック中なので基点の更新は発生しない) > > 3. 実体カーソルを 100 → 200 → 300 行目へ順に移動して各箇所を処理 > > 対処法としては、こちらを次のようにするくらいしか思いつかず……。 > > 2. 100 行目だけ（元の実体カーソルの位置だけ）処理し、基点更新をロック > 3. 200 → 300 行目と処理していく。 > > こちらの方がよっぽど無理矢理ですね (^^;

マークダウンを有効にする