ペインを分割したときのカーソル位置

1. 行の表示を"折り返さない"と"指定文字数で折り返し"の場合は、分割or解除してもカーソル位置は狂いません
   ですが、"ウインドウの右端で折り返し"にしておくと、分割or解除したときにカーソル位置が飛んでしまいます

   Ver.3.2.0です

   2020年11月11日 22:29  |  かずら  |  返信

2. ご報告ありがとうございます。

   確認してみましたが現象を再現することができませんでした。

   もしかして、折り返しをはさんだ行末や行頭にカーソルがある場合のことではないでしょうか？

   以下の条件下ではそういった問題が発生します。

   [指定文字数で折り返し] や [ウィンドウの右端で折り返し] でカーソルがちょうど折り返し位置と同じ位置にある状態でウィンドウの分割・解除を行った場合、カーソル位置は保持されますが行と桁 (X、Y 座標) は保持されません。

   折り返しをはさんだ行末と行頭の位置は X、Y 座標は異なりますがカーソル位置としては同じなため、折り返しをはさんで行頭にあったカーソル位置が前の行の行末に移動したりなどが発生します。

   ウィンドウの分割・解除だけでなく、ファイルを開いたときのカーソル位置の復元などにおいても同様です。

   エディターの構造上、技術的に対応が困難だと思いますので、仕様上の制限事項ということでご了承ください。

   ちなみに、他のエディターの挙動も確認してみましたところ、Visual Studio Code や Brackets など、折り返しを挟んで行末と行頭にカーソルを移動できるタイプのエディターですと同様の問題が発生しました。

   2020年11月12日 20:51  |  Kuro  |  返信
3. Kuro さんの投稿 (2020年11月12日) への返信

   > もしかして、折り返しをはさんだ行末や行頭にカーソルがある場合のことではないでしょうか？

   カーソル位置に影響は受けません
   行末・行頭は言うに及ばず、行中でも発生します

   > ウィンドウの分割・解除だけでなく、ファイルを開いたときのカーソル位置の復元などにおいても同様です。

   ウインドウではなくペインです
   ペインの上下分割・左右分割のどちらでも発生します

   １６０００行目にカーソルを置いて分割すると、１０５０１行目辺りから表示されます
   この状態で↑キーを押すと、表示されている最後の行辺りからカーソルが現われます
   ↓キーを押すと１６００１行目にカーソルと表示が移動します。
   分割前に１６０００論理行で表示されていたのが、分割したら１６０００表示行で表示されたみたいな感覚でしょうか

   表示モードが"ウインドウの右端で折り返し"に設定した場合のみ、問題が発生します

   2020年11月12日 22:39  |  かずら  |  返信
4. かずら さんの投稿 (2020年11月12日) への返信

   > １６０００行目にカーソルを置いて分割すると、１０５０１行目辺りから表示されます
   > この状態で↑キーを押すと、表示されている最後の行辺りからカーソルが現われます

   それは単純に矢印キーの機能でジャンプしてるだけで、カーソルは維持されてます。
   試しに左右矢印でやってみてください。

   問題としては
   ・折り返し長変化時にカーソルを画面内に収めるためのスクロール位置調整が行われない時がある(調整後の折り返し増加量とか行の距離に因る？)
   通常の「表示」→「折り返さない」からの「ウィンドウの右端～」又は仕切りのドラッグで折り返し長の変更時ではアクティブペインは調整されるが
   左右画面分割時の折り返し長変化時に調整されないことがある。

   ・左右画面分割時は同じ画面がコピーされるのでスクロール量もアクティブ側からそのまま流用すればいいのでは？(折り返し長変化による変更後の値になるが)

   2020年11月13日 19:54  |  MM  |  返信

5. 確認してみましたが、MM さんのおっしゃるとおり、カーソル位置は維持されていますね。

   また、ウィンドウ分割ではなく、ペインの分割とのことで、ちょっと状況が把握できていません。

   ペインの分割というのはウィンドウ分割ではなく、アウトラインプラグインなどを表示した状態、という理解で合っていますでしょうか？

   例えば右側にアウトラインプラグインを表示するとエディター部分の幅が変更されますので、当然 [ウィンドウの右端で折り返し] の "右端" も変わってきますので折り返し位置を変更したことになります。

   折り返し位置を変更した場合、Mery の仕様ですと表示座標を基準に折り返しを計算していますので、スクロール位置が維持されたまま折り返しの変更が行われます。

   その結果、もともと画面上の 1 行目に表示されていた箇所が画面外に移動したり、カーソル位置が画面外に移動したりなどは発生します。

   > ・折り返し長変化時にカーソルを画面内に収めるためのスクロール位置調整が行われない時がある(調整後の折り返し増加量とか行の距離に因る？)
   > 通常の「表示」→「折り返さない」からの「ウィンドウの右端～」又は仕切りのドラッグで折り返し長の変更時ではアクティブペインは調整されるが
   > 左右画面分割時の折り返し長変化時に調整されないことがある。

   これはアクティブ側の表示座標を基準にしているため、そう見えるだけだと思います。

   論理座標を基準にすることもできるのですが、そうするとルーラーの部分をドラッグして折り返し位置をリアルタイムで動かしたときに、例えばちょっと行きすぎちゃって元に戻したときなどに、元の状態を完全には復元することができなくなってしまいますので。

   > ・左右画面分割時は同じ画面がコピーされるのでスクロール量もアクティブ側からそのまま流用すればいいのでは？(折り返し長変化による変更後の値になるが)

   既にそういう仕様になっていますね。(折り返し長変更後の値ですが)

   状況が把握できておらず、探り探りの回答となってしまって申し訳ないですが、具体的な例などを挙げていただけると助かります。

   2020年11月13日 21:48  |  Kuro  |  返信
6. Kuro さんの投稿 (2020年11月13日) への返信

   確かにカーソル位置は維持されているようですね
   私の誤認で勘違いさせてしまったようで、申し訳ない
   ウインドウやペインという表現についても、誤解していたようです

   要するに、n行目を表示させておいたときに"コマンド 上下に分割"あるいは"コマンド 左右に分割"で分割させたときに、n行目が表示されていない(カーソルが画面外に飛んでいる)ということです
   解除したときも、 n行目が一応表示されてはいるものの、中央付近にあったn行目が、前や後ろの方に飛んでいたりして視認性が悪くなっています

   n行目を見たり修正したりしながら、他の場所を見たり修正したりしたいのです
   見えていたものが意図せず見えなくなるのはおかしい、と感じているわけです

   "折り返さない"或いは"指定文字数で折り返す"の場合、表示幅が変わっても表示行数が変わらないので、そういった現象は発生しません
   ですが、"ウインドウの右端で折り返し"の場合は、表示幅が変わるために表示行数が変わってしまうため、こういった現象が発生するのだと思います
   n行目が表示行数でm行目だった場合、分割すると前者の場合はm行目で変わりません
   ですが後者の場合はn行目がm+x行目に変化するのにもかかわらず、表示位置がm行目から変わっていないため、本来見えているべきものが画面外に飛んでしまうのだと思います。

   2020年11月14日 8:50  |  かずら  |  返信
7. かずら さんの投稿 (2020年11月14日) への返信

   追伸
   "n行目"は論理行数のことです

   2020年11月14日 9:20  |  かずら  |  返信
8. かずら さんの投稿 (2020年11月14日) への返信

   折り返し位置を変更した場合、画面上に表示できる文字数が増えたり減ったりするわけですから、見えていたものが画面外に移動して見えなくなるという状況は必ず発生します。

   他のエディターの仕様も確認してみましたが、同様の操作において Visual Studio Code、Atom、Brackets、Sublime Text、サク〇エディタさん、E〇Editor さん、いずれも見えている箇所やカーソルが画面外に飛んでいくケースがありました。

   そもそも、ユーザーがどこを見ているかというのはプログラムからは判断しようがありませんからね。

   先頭行 (論理行数) を基準にするとカーソル行や末尾行を見失いますし、カーソル行を基準にすると先頭行や末尾行を見失います。

   ちなみに Brackets は Mery と同じで先頭行 (表示行数) 基準、Visual Studio Code は先頭行 (論理行数) 基準となっているようですが、カーソル行を基準にしているものは見当たりませんでした。

   先頭行 (論理行数) 基準は下方向に拡張するのでカーソル位置を見失いやすいですが、先頭行 (表示行数) 基準は上下に収縮・拡張しますのでカーソル位置をそこそこ追いやすいと思います。

   あとは、やるとしたら、ユーザーが見ているのはカーソル位置だという前提のもとに、現状の先頭行 (表示行数) 基準の仕様を維持しつつ、カーソルが画面外に飛び出したらできるだけカーソルに追従していく仕組みなら作れるかもしれません。

   それでもカーソル位置は大きく移動するので、少しは見つけやすくなるかもといった程度だとは思いますが。

   2020年11月14日 22:46  |  Kuro  |  返信
9. Kuro さんの投稿 (2020年11月14日) への返信

   > そもそも、ユーザーがどこを見ているかというのはプログラムからは判断しようがありませんからね。

   単純に現在表示しているものの中央が変化しなければ、十分だと考えています
   そうすれば現在目に見えているものの変化が最低限に抑えられるとも考えています
   n行目から表示しているわけだから、ユーザーが何処を見ているかはそれで判断すれば良いと思います

   カーソルの位置云々は、通常カーソルは見えている画面内に収まっていることが大半と言うことを前提で話していました
   カーソルが画面外であろうが、画面内であろうが、目に見えているものがほぼ変化無ければ、問題は無いと考えています

   重要なのは「現在目に見えているものが、今の仕様だと意図せず消えて無くなる」と言うことが変だ、と言っているのです
   「現在目に見えているものが、見えた状態のまま」なのが理想なのです
   もちろん、表示範囲が狭くなるのだから、注目箇所の前後が見えなくなってしまうのは当然です

   文章全体をa-zの２６ブロックに分けたとして、現在h-nの７ブロックが表示されているとしましょう
   分割すると表示範囲が狭くなるので４ブロックしか表示されないと仮定しましょう
   現在は分割されるとc-fが表示されるような仕様になっています
   これをi-lが表示されるような仕様になるだけでも、視認性は向上すると思います
   つまり、画面の中央に表示されているブロック(文字列)がほぼ変化していない、ということです
   とりあえず、上記案ではカーソル位置は考慮していません

   2020年11月15日 1:06  |  かずら  |  返信
10. かずら さんの投稿 (2020年11月15日) への返信

    中央ということでしたら現在の仕様 (表示座標の先頭行基準) が一番それに近いかと思います。

    論理座標基準で中央にある行を維持する場合、折り返しを挟んだ行が中央付近にあると論理座標の先頭が中央に移動することになるので、先頭行もズレ、中央行もズレ、末尾行もズレるという、よく分からない状態になります。

    参考のため他のエディターの仕様も確認してみましたところ、以下のようになっていました。

    ▼ 論理座標の先頭行基準
    Visual Studio Code 1.49.1
    Sublime Text Build 3.2.2
    Notepad++ 7.9.1
    秀〇 8.93
    E〇Editor 20.2.2
    サク〇エディタ 2.4.1

    ▼ 表示座標の先頭行基準
    Adobe Brackets 1.14.2
    UltraEdit 27.10.0.148
    メモ帳
    Mery 3.2.1

    ▼ カーソルのある行基準
    WZ Editor 10 64bit

    残念ながら中央行を基準としたものは見当たりませんでした。

    「論理座標の先頭行基準」は国産のテキストエディターでも採用されているようですが、先頭行が完全に固定されてしまうので、中央付近を維持という点からすると「表示座標の先頭行基準」のほうがマシです。

    「カーソルのある行基準」はなかなか面白いのですが、その仕様に気づくまでは先頭行と末尾行が大きくずれるので「え？」となってしまいました。

    Windows 標準のメモ帳が「表示座標の先頭行基準」となっていることですし、やはり現状の仕様を維持とさせていただければと思います。

    この仕様に加えて、カーソル位置が画面外に出たときはなるべく追従するような仕組みができないか、またその仕組みによって視認性が向上するかも含めて検討してみたいと思います。

    2020年11月15日 11:50  |  Kuro  |  返信
11. Kuro さんの投稿 (2020年11月15日) への返信

    > 「論理座標の先頭行基準」は国産のテキストエディターでも採用されているようですが、先頭行が完全に固定されてしまうので、中央付近を維持という点からすると「表示座標の先頭行基準」のほうがマシです。

    論理座標基準でも表示座標基準でも、見えているものが画面外に消えなければ、ユーザーとしてはどっちでも良いんです
    内部処理的なものがなんであれ、ユーザーに見えるのはその結果ですから(仕事でもよく言われますw)
    表示可能情報量が変化するのですから、全てが同じといかないのは分かります
    ですが、現状(表示座標の先頭行基準)では全てが画面外に消えてしまいます
    先頭行と末尾行が多少削れたところで、全て無くなるほどの驚きはないと思います

    2020年11月15日 14:07  |  かずら  |  返信
12. かずら さんの投稿 (2020年11月15日) への返信

    > 論理座標基準でも表示座標基準でも、見えているものが画面外に消えなければ、ユーザーとしてはどっちでも良いんです

    開発する側からしてもどちらでも良いのですが、画面の中央を基準に折り返し位置を変更するタイプのエディターが見当たらない以上、それが一般的な仕様とは思えないのです。

    ユーザーが使いやすければ良いというご意見はごもっともですが、Mery はメモ帳からのステップアップというコンセプトのもと、テキストエディターに慣れてきたらどんどん他のエディターに乗り換えていただければということで、より一般的な仕様を採用していくことが使いやすさにつながると考えています。

    本件につきましてはご要望どおりの仕様というわけにはいきませんが、現状の仕様にカーソル位置追従を加えることである程度は視界から消える範囲を少なくすることができると思いますのでご了承ください。

    2020年11月15日 14:48  |  Kuro  |  返信

13. > この仕様に加えて、カーソル位置が画面外に出たときはなるべく追従するような仕組みができないか、またその仕組みによって視認性が向上するかも含めて検討してみたいと思います。

    表示座標の先頭行基準 + できるだけカーソル位置追従方式、ほぼ 1 日かかりましたがなんとか完成です。

    …が、実際に使ってみると「見えているもの (カーソル位置付近)」が画面外に飛び出すことはないものの、基準が先頭行とカーソル位置の 2 つあることによって、ユーザー側からするとどちらに注目すれば良いのかわからないという問題が出そうです。

    やはり、メモ帳準拠ということで現状維持のままか、ユーザーが見ているのは先頭行付近だという前提になりますが論理座標の先頭行基準にするかのどちらかですね。

    エディターコンポーネントの構造上、論理座標の計算は非常に遅いのでポンコツになる可能性もありますが、技術的には興味があるので、一応、論理座標の先頭行基準にも挑戦してみたいと思います。

    どちらの方式にするかは、もう少し研究を重ねた上で、動作速度と座標の見失いにくさを確認してから改めて検討させていただきたいと思います。

    2020年11月15日 21:00  |  Kuro  |  返信

14. 引き続き調査しておりましたところ、さらなる発見がありました。

    論理座標の先頭行基準だと思っていたエディターの中でも、いくつかタイプがあるようです。

    ----------------------------------------------------------------
    ▼ 完全に論理座標の先頭行基準

    秀〇 8.93

    このタイプは折り返し幅を少しでも変更すると先頭行が論理座標の先頭に吸着します。

    ・良い点
    先頭行が完全に固定されるので、先頭行に注目している場合は見失いにくい。

    ・悪い点
    先頭行が折り返しを挟んだ途中にある場合は、論理座標の先頭に吸着するので見失いやすい。また、先頭行は完全に固定なので中央付近の行は下方向に大きく移動します。

    ▼ 微妙に論理座標の先頭行基準

    Notepad++ 7.9.1
    サク〇エディタ 2.4.1

    このタイプは先頭行の論理座標が変わってしまう場合のみ、先頭行が論理座標の先頭に吸着します。

    ・良い点
    「完全に論理座標の先頭行基準」より変化がゆるやか。

    ・悪い点
    折り返し幅が一定を超えると、突然、画面外から現れた論理座標の先頭に吸着するので違和感がある。一度、吸着してしまえばその後は「完全に論理座標の先頭行基準」になる。

    ▼ 先頭行の最初の文字基準

    Visual Studio Code 1.49.1
    E〇Editor 20.2.2

    このタイプは表示座標でも論理座標でもなく、先頭行の最初の文字の箇所を目印にして、折り返し幅を変更したときにその目印が先頭行に来るようにスクロール位置を調整するようです。

    ・良い点
    折り返し幅を変更したときに先頭行付近の移動距離に違和感が少なく、見失いにくい。

    ・悪い点
    折り返し幅を広げて先頭行が論理座標の先頭に達した時点で「完全に論理座標の先頭行基準」に固定される。

    ▼ 謎

    Sublime Text Build 3.2.2

    論理座標の先頭行基準かと思ったのですが、折り返し幅を大きく広げると先頭行の論理座標がズレてしまいますので、先頭行が論理座標の先頭に吸着するわけでもなさそうです。
    ----------------------------------------------------------------

    どのタイプでも折り返し幅によっては「完全に論理座標の先頭行基準」タイプに移行するわけですが、実際に色々と折り返し幅を変更して試してみて、個人的に違和感が少なくて、画面上に見えているものを見失いにくいのは Visual Studio Code 方式だと感じました。

    そして実装として一番難しそうなのも Visual Studio Code 方式だと思いますが、なかなか手ごたえのありそうな案件なので開発に挑戦してみたいと思います。

    2020年11月17日 21:01  |  Kuro  |  返信
15. Kuro さんの投稿 (2020年11月17日) への返信

    > どのタイプでも折り返し幅によっては～略～
    > そして実装として一番難しそうなのも Visual Studio Code 方式だと思いますが、なかなか手ごたえのありそうな案件なので開発に挑戦してみたいと思います。

    いやいや、そこでモチベ上がるんですかｗ

    ウィンドウのリサイズすると、カーソルがアクティブになるのか
    折り返し長変化による表示上改行数が増減してもカーソルがある位置に
    スクロール位置(画面)が遷移するじゃないですか？(うちの環境だけ？)。

    画面分割時もアクティブペインの方はそうなるのでそれで(を故意に起こせば)いいんじゃないでしょうか。
    あるいは(ノンアクティブペインは)、表示上改行数の増減量に比例して...ってそれじゃどっちも、綺麗さも正確さもないし駄目ですねｗ(カーソルや座標の追従も、戻したときの再現性もない)。

    2020年11月17日 22:59  |  MM  |  返信
16. MM さんの投稿 (2020年11月17日) への返信

    書き忘れてました！ 前回のレスではMeryの標準動作を勘違いして書いており、混乱のもとになったかも。すいませんでした。

    2020年11月17日 23:16  |  MM  |  返信
17. MM さんの投稿 (2020年11月17日) への返信

    > いやいや、そこでモチベ上がるんですかｗ

    いえー、むしろ半泣きですw

    > カーソルがある位置にスクロール位置(画面)が遷移するじゃないですか？(うちの環境だけ？)。
    > 画面分割時もアクティブペインの方はそうなるのでそれで(を故意に起こせば)いいんじゃないでしょうか。

    はい、それがまさに「表示座標の先頭行基準 + できるだけカーソル位置追従方式」と書いていた提案です。説明が分かりづらくてすみません。

    とは言ってもアクティブじゃないほうを故意に再描画するための機構が用意されてなくて、それを 1 日かけてせっせとこしらえていました ^^;

    > ってそれじゃどっちも、綺麗さも正確さもないし駄目ですねｗ(カーソルや座標の追従も、戻したときの再現性もない)。

    そうなんですよね。実際に色々なエディターの動作を確認していて分かったのですが「戻したときの再現性」というのは重要で、先頭だけでも良いので少しでも同じ文字列が固定された状態で画面上に残っていれば、人間の目は自然にそこに吸い寄せられるんだと思いました。

    > 前回のレスではMeryの標準動作を勘違いして書いており、混乱のもとになったかも。すいませんでした。

    お気になさらず。私もしばしば勘違いやド忘れしますので、その際はお手柔らかにお願いいたします。

    2020年11月18日 21:56  |  Kuro  |  返信
18. Kuro さんの投稿 (2020年11月18日) への返信

    Ver.3.2.3にて確認
    対応ありがとうございます
    視認エリアがほぼ変わらなくなったので、編集がしやすくなりました

    ただ一点
    画面分割しているとき、アクティブな方のカーソル位置は変わりませんが、非アクティブな方のカーソル位置が変化してしまいます

    再現手順
    1.表示を「折り返さない」或いは「指定文字数で折り返し」にしておく
    2.画面を分割する
    3.表示を「ウインドウの右端で折り返し」にする

    こうすると、非アクティブな方のカーソルが移動してしまいます
    カーソルのある行の色を変えるようにしておくと、よく分かります
    もちろん、逆でも発生します

    2021年1月1日 2:09  |  かずら  |  返信
19. かずら さんの投稿 (2021年1月1日) への返信

    ご報告ありがとうございます。

    現象、確認しました。ウィンドウ分割時のカーソル位置の同期ですが、どうしても動作速度に満足できなくて Ver 3.2.2 でロジックをすべて作り直したのです。

    折返し位置の変更とか改行を入れるとズレてしまいますね。これはもう少し研究して出直してきたいと思います。

    2021年1月4日 21:14  |  Kuro  |  返信