固定スクロール有効時、マルチカーソル・上部の余白について
-
初めまして！長らく（こっそり）愛用させていただいております。
Ver 3.7.16 のアップデートで気になっていた部分が改修され、とてもありがたかったので、思い切って私も投稿してみます。
という勢いで書きましたが勘違いでした(><; それはまた改めて……【マルチカーソル】
- タイプライタースクロールをオン、位置：可変、固定スクロールをオン
- 矩形選択／Ctrl+D（選択範囲に次の候補を追加）／Ctrl+クリックなど、マルチカーソル状態にする
- 貼り付け／括弧を入力（括弧/引用符で選択範囲を自動的に囲む）すると、スクロール位置が変わる
※2の方法やカーソル位置によって変わらない場合もありますが、マルチカーソルが画面外にもあれば100%変わります。
いずれも文字入力した場合はスクロール位置が変わらないので、それに合わせていただけると助かります。
【上部の余白】
固定スクロールを有効にして最終行付近までスクールすると、スクロール位置に応じた余白が下部に現れます。目線が移動しないので見やすいです。同じように、先頭行付近にいるときは上部にも余白ができると嬉しいです。
……これはかなり外観が変わるので難しそうですが、当たって砕けろで挙げてみました。
現在は文書の先頭に改行を入れてそれっぽくしています(^^;Mery: 3.7.16 (x64, Portable)
Onigmo: 6.2.0
C/Migemo: 1.3
Tidy: 5.8.0
Hunspell: 1.7.1
uchardet: 0.0.8
アウトライン: 3.2.3 (Outline.dll)
OS: Windows 10 (Version 22H2, OS Build 19045.5854, 64-bit Edition)| nimx | 返信 -
はじめまして。Mery をご愛用いただき、ありがとうございます。
タイプライタースクロールは、カーソルを画面上の一定位置に固定することで視点の移動を抑える機能で、主に執筆用途を想定しています。
一方、マルチカーソルは複数箇所を同時に編集できる機能で、主にプログラミングにおけるコード編集を想定しています。
このように、前者は単一カーソル用、後者は複数カーソル用の機能となっており、性質上相反するため、もともと同時使用は想定していませんでした。
そのため、ご要望の件については現行の Mery の仕様にはない使い方となりますので、まずはどのような仕様が適切かという検討から始める必要があります。
少し長くなりますが、以下に仕様についての考察をまとめてみました。
まず、用語や機能の意味を共有するため、現行の仕様について簡単にご説明します。
- タイプライタースクロールの [可変] モードについて
[可変] モードでは、「マウスでクリックした位置」または「最後に編集した位置」を基点とし、その位置が画面内に留まるようにスクロールします。
- マルチカーソル編集について
Ctrl + マウスクリックや特定のコマンドによって複数のカーソルを表示し、同時に編集ができる機能です。
見た目には複数のカーソルが存在するように見えますが、Windows の仕様上、実際には 1 つの「実体カーソル」のみが存在しています。(Windows 10 で一定時間操作しないと点滅が止まるカーソルが実体です)
この実体カーソルは、通常は「最後に追加されたカーソル」が該当しますが、編集や移動の操作によって変化することがあり、ユーザーが明示的に指定することはできません。
また、見た目は同時編集のように見えても、内部的には順序を最適化して 1 箇所ずつ編集しています。
- タイプライタースクロールの [可変] モード + マルチカーソル編集
この組み合わせでは、[可変] モードの基点が「最後にクリックした位置 (実体カーソル)」または「最後に編集した位置」となります。
たとえば Ctrl + クリックでカーソルを追加した場合、その位置が基点となります。
ただし、マルチカーソル編集では、編集順序が内部的に自動で決まるため、「最後に編集した位置」をユーザーが意図的にコントロールすることができません。
そのため、タイプライタースクロールの基点が意図しない位置に設定される場合があります。
> ※2の方法やカーソル位置によって変わらない場合もありますが、マルチカーソルが画面外にもあれば100%変わります。
はい、そのとおりです。
現行の仕様では、マルチカーソルの有無にかかわらず、画面外で編集が行われた場合には、タイプライタースクロールの基点は「画面中央」に移動するようになっています。
ただし、条件によっては「画面下部」に移動するケースもあるようで、これは本来の仕様ではなく想定外の挙動です。
【仕様変更案】
タイプライタースクロールとマルチカーソルを同時に使えるようにするには、両者の性質の違いを調整する必要があります。
そこで、Mery 側で対応可能な範囲として、以下のような仕様を考えてみました。
-
マルチカーソル使用時、基点は「最後にクリックした位置」とする (現行の仕様を維持)
→ Ctrl + クリックで追加されたカーソル位置をタイプライタースクロールの基点とする動作はそのまま残します。
→ 「常に 1 つ目のカーソルを基点とする」案も検討しましたが、基点が固定されることで編集位置を見失いやすくなるため、見送りました。 -
マルチカーソル編集時には、基点 (最後に編集した位置) を更新しない
→ 単一カーソル時には編集に応じて基点が更新されますが、マルチカーソル編集中はこの挙動を無効化し、基点の変更を防ぎます。これによりスクロール位置が安定する効果が期待できます。 -
カーソルが画面外の状態で編集したとき、基点を「画面中央」にしない
→ Scrivener 風の「画面中央へスクロールする」仕様は廃止し、基点を維持するようにします。
上記 3 点の変更により、ご要望の挙動に近い動作が実現できるかと思います。
ただし、以下の点については確認が必要です。
> いずれも文字入力した場合はスクロール位置が変わらないので、それに合わせていただけると助かります。
この「スクロール位置が変わらない」というのが「タイプライタースクロールの基点を変更しない」という意味であれば、上記の仕様変更で対応可能かと思います。
つまり、タイプライタースクロールの基点は維持されますが、スクロール位置が固定されるわけではないので、カーソルが画面外の状態で編集した場合は、タイプライタースクロールの基点までスクロール位置が移動します。
ただし、もし「画面外で編集しても、画面自体のスクロール位置がまったく動かないようにする」という意味であれば、これはタイプライタースクロールの根本的な挙動と矛盾するため、現状では対応が難しいかと思います。
> 同じように、先頭行付近にいるときは上部にも余白ができると嬉しいです。
>
> ……これはかなり外観が変わるので難しそうですが、当たって砕けろで挙げてみました。
> 現在は文書の先頭に改行を入れてそれっぽくしています(^^;ご推察のとおり、上方向に余白を設けるにはエディターの設計自体を見直す必要があり、私の技術力では対応が難しいところです。
こちらについてはご要望ということでいただいておきますね。
ちなみに Mery のタイプライタースクロールは、技術的な好奇心から試しに作ってみただけなので、もっと本格的に使いたい場合は、本家 Scrivener のほうもチェックしてみてくださいね。
【参考】Scrivener
https://www.literatureandlatte.com/scrivener/overview……とはいえ、Scrivener でも「上方向の余白」はできないようですが ^^;
また、マルチカーソルのような機能は執筆系エディターではあまり見かけないため、「タイプライタースクロール + マルチカーソル」という組み合わせ自体が、難易度の高いテーマなのかもしれませんね。
| Kuro | 返信 -
詳しくご説明くださり、ありがとうございます。
返信が遅くなってすみません。
私の認識が浅く、検証と理解に時間がかかっておりました。
ようやくまとまりましたので、長くなりますが、お読みいただけると幸いです。【使用方法について】
> このように、前者は単一カーソル用、後者は複数カーソル用の機能となっており、性質上相反するため、もともと同時使用は想定していませんでした。
想定外の使い方という自覚がなく、お手数をおかけしてすみません。
「講演などをAIで文字起こししたもの」を校正・編集するようになり、キー操作で読みながら編集できるタイプライタースクロールを使うようになったのですが、いつもの癖でマルチカーソル機能も当たり前のように使っていました。
編集箇所を見つけては同じようなところをまとめて書き換えることも多く、複雑なものには置換を使いますが、簡易的に使えて編集履歴も一つになる複数選択（Ctrl+D / Shift+Ctrl+D）がとても便利なんです。
目線が固定されること、前後の文が見えるので修正の判断がしやすいこと、書き換え後に上キーを押すと先頭のカーソルにスクロールする（ような感じになる）ことも愛用ポイントです。
マウスを使わないことも利点なのですが、それによって「基点が画面中央にスクロールする」という仕様には気付かず、「貼り付け時には画面下部にスクロールする」とばかり思っておりました。
「実体カーソル」が画面内にある場合、他のカーソルが画面内外どこにあっても、文字入力ではスクロールしないんですね。
「スクロール位置が変わらない」とは、そういう意味でした。【検証結果】
ここで、検証結果を表にしたのでご覧ください。
https://imgur.com/a/4DNyZ0o読み方の例：
-
直接入力したとき、〈実体カーソル〉が画面外（上）にあれば、（実体カーソルが）画面中央に移動する
→ 最終的な基点表示位置は「画面中央」 -
貼り付けしたとき、〈全カーソル〉が（画面半分以下の高さで）画面外（上）～画面内（中央）にあれば、〈先頭カーソル〉が画面中央に移動する
画面更新時、〈実体カーソル〉が編集後の最後尾カーソルの位置に移動する
→ 最終的な基点表示位置は「編集後の最後尾カーソルの位置」*画面更新時とは、マルチカーソルを解除、左右キーでのカーソル移動、入力文字を確定といった操作です。
ちなみに 単一カーソル時、文字入力はほぼ同じ、貼り付けは直接入力と同じ挙動になりました。
ここに、いただいた仕様変更案を当てはめて考えてみました。
【仕様変更案について】
> - マルチカーソル使用時、基点は「最後にクリックした位置」とする (現行の仕様を維持)
> - カーソルが画面外の状態で編集したとき、基点を「画面中央」にしない上記２点はそのまま賛同します。
想定外の「画面下部」になる挙動のこともありますが、やはり可変モードを使っているからには、指定した基点位置を維持していただけるのがありがたいです。
> - マルチカーソル編集時には、基点 (最後に編集した位置) を更新しない
> → 単一カーソル時には編集に応じて基点が更新されますが、マルチカーソル編集中はこの挙動を無効化し、基点の変更を防ぎます。これによりスクロール位置が安定する効果が期待できます。こちらについては、次のようにしていただくことは可能でしょうか。
- マルチカーソル編集時には、基点を「実体カーソルの位置」とする
あるいは同じ意味なのかもしれませんが、「単一カーソル編集時は更新し、マルチカーソル編集時は更新しない」となるので、別だと考えました。
常に実行カーソルが基点となることで、単一カーソル編集と変わらない使用感となり、スクロール位置も安定すると思います。
合わせて、もうひとつ提案させていただきます。
- 基点が画面内の状態で編集したとき、スクロールしない
マウススクロールによって実体カーソル表示位置が基点表示位置から外れたとき、そこを新たな基点表示位置とし、スクロールしないようにします。
現行の日本語入力での仕様を他に合わせるもので、こちらもスクロール位置の安定につながると思います。
この４点で、よろしくお願いいたします。
【おわりに】
あらめまして、仕様変更をご検討くださり、ありがとうございます。
Mery はシンプルな外観や使い勝手ながら、たくさんのことができるようになっているので（だからこそ替えがきかないのですが）、仕様を突き詰めて考えるのは大変ですね。
今回の検証を通して、その一端を垣間見た気がします。
ご紹介いただいた Scrivener をダウンロードしましたので、これから試してみます。
本家ということで気になりますが、きっと私が使いたいのは「Meryのなかのタイプライタースクロール」なのだろうなとは思っています (^^| nimx | 返信 -
-
ご返信ありがとうございます。
> 私の認識が浅く、検証と理解に時間がかかっておりました。
> ようやくまとまりましたので、長くなりますが、お読みいただけると幸いです。
> 想定外の使い方という自覚がなく、お手数をおかけしてすみません。いえいえ、お気になさらないでください。私のほうも仕様の整理に時間がかかり、返信が遅くなってしまいました。
実のところ、タイプライタースクロールは私自身あまり使っておらず、ユーザーさんの中でも利用されている方は少ない機能なので、実際に活用されている方からご意見をいただけるのはありがたいです。
仕様を検討するにあたり、改めて調べてみたところ、VSCode や Sublime Text では拡張機能を導入することでタイプライタースクロールが使えるようだったので、実際に試してみました。
どちらもマルチカーソルに対応していたため、「タイプライタースクロール + マルチカーソル」での挙動を検証しています。
VSCode (拡張機能を 3 つほど試しました)
- マルチカーソルとの組み合わせは想定されていないようです
→ タイプライタースクロールとマルチカーソルがカーソル位置を奪い合うような動作になり、編集やカーソル移動のたびにスクロール位置が上下に揺れてしまいます。
Sublime Text
- 「マルチカーソルで動作するようには設計されていない」といった注意書きがありました
→ カーソルが 2 つ以上になると、自動的にタイプライタースクロールが無効になるようです。
また、どちらのエディターにも Mery の「可変モード」に相当するような機能は見当たりませんでした。
その他のエディターもざっと調べてみましたが、タイプライタースクロールはあるけどマルチカーソルがない、またはその逆、といったケースが多く、両立しているものは見つかりませんでした。
ということで、やはり独自に仕様を検討する必要がありそうです。
> 【検証結果】
>
> ここで、検証結果を表にしたのでご覧ください。
> https://imgur.com/a/4DNyZ0oわざわざ表までご用意いただきありがとうございます。文字だけでは伝わりにくい部分もあるので、とても助かります。
> > - マルチカーソル使用時、基点は「最後にクリックした位置」とする (現行の仕様を維持)
> > - カーソルが画面外の状態で編集したとき、基点を「画面中央」にしない
>
> 上記２点はそのまま賛同します。こちら 2 点、賛同いただきありがとうございます。ひとまず、この仕様で進めてみたいと思います。
> こちらについては、次のようにしていただくことは可能でしょうか。
> マルチカーソル編集時には、基点を「実体カーソルの位置」とする現在の仕様でも、マルチカーソル編集時は基点が「実体カーソルの位置」に更新されるようになっています。
そのため、マルチカーソルで [貼り付け] を行うと、意図しない位置に基点が移動してしまう、という問題が起きています。(これは、マルチカーソルでの [貼り付け] が、実体カーソルを動かしながら順に処理しているためです)
この問題に対処するため、「単一カーソル時のみ基点を更新し、マルチカーソル時は更新しない」という仕様を提案させていただいたのですが、こちらについては、いったん現状維持としましょうか。
別のアプローチとして、マルチカーソル時の [貼り付け] 処理について、他の編集操作と同様のスクロール挙動にそろえることで、スクロールの乱れをある程度抑えられるかもしれません。
(いただいた表の 1 枚目、2 枚目の「貼り付け」のケースを「直接入力」と同じ挙動にするイメージです）
> 合わせて、もうひとつ提案させていただきます。
>
> 基点が画面内の状態で編集したとき、スクロールしない
> マウススクロールによって実体カーソル表示位置が基点表示位置から外れたとき、そこを新たな基点表示位置とし、スクロールしないようにします。この挙動については、現行仕様でも基本的にはそのようになっていると思います。ただ、日本語入力に関しては少し事情が異なります。
> 現行の日本語入力での仕様を他に合わせるもので、こちらもスクロール位置の安定につながると思います。
現在の仕様では「編集が行われたとき」に基点が更新されるため、IME 変換中の未確定状態では基点が更新されず、その結果スクロールが発生してしまう、という流れになります。
これに対応するには、「日本語入力の開始時」に基点を更新する必要があります。
ただしこの場合、IME 入力をキャンセルしても基点だけが更新されてしまうことになるため、その点はある程度の妥協が必要になりそうです。
> ご紹介いただいた Scrivener をダウンロードしましたので、これから試してみます。
> 本家ということで気になりますが、きっと私が使いたいのは「Meryのなかのタイプライタースクロール」なのだろうなとは思っています (^^ありがとうございます ^^
そういえば、Scrivener の Windows 版は、タイプライタースクロール関連の機能があまり充実していなかったことを思い出しました…。
Mac 版では、Mery のように「カーソル位置を画面下 1/4 に固定」といった指定ができたり、カーソル行以外をグレーアウトする「フォーカスモード」があったりするのですが、Windows 版はちょっとシンプルなんですよね。
ともあれ、今回いただいたご提案や検証結果をもとに、次回バージョンで試験的に新しい仕様を実装してみたいと思います。
かなり複雑な仕様になりそうですが、まずはかたちにしてみて、実際の使い心地を確認しながら調整していけたらと思います。
| Kuro | 返信 - マルチカーソルとの組み合わせは想定されていないようです
-
Scrivener のタイプライタースクロール部分は、固定スクロールもなく、「編集時、画面中央にカーソルを移動・維持する」というシンプルな仕様でした。
（エディタとしては、ヘルプファイルを思わせる構造で、情報をまとめるのに使いやすそうでした。これはこれで面白いですね）お調べくださった情報も合わせて、基本的にタイプライタースクロールとマルチカーソルは相容れない機能で、Meryが文字入力に対応していることが特別な状態だったんですね。
難しい要望にお付き合いくださりありがとうございます。> 現在の仕様でも、マルチカーソル編集時は基点が「実体カーソルの位置」に更新されるようになっています。
>
> そのため、マルチカーソルで [貼り付け] を行うと、意図しない位置に基点が移動してしまう、という問題が起きています。(これは、マルチカーソルでの [貼り付け] が、実体カーソルを動かしながら順に処理しているためです)マルチカーソルでの [貼り付け] 直後、基点表示位置には最後尾のカーソルが表示されている（元の実体カーソルが最後尾でなかった場合、別の位置に実体カーソルがある）ので、どうにも理解が及びません……。
次のような認識だったのですが、ここが違っているのかもしれません。
- 「基点を○○に更新する」とは、○行○列といった文書内の位置を主に指す（表示位置が含まれることもある）
- 「基点を○○に移動する」とは、画面中央といった画面内の表示位置を指す
具体的には、カーソルが 文書の100行目（実体）・200行目・300行目にある場合
- [貼り付け] を行うと、300行目が画面下部に表示されます。
- ここで マルチカーソルを解除・左右キーでのカーソル移動・入力文字を確定といった操作を行うと、100行目が画面下部に表示されます。
1のとき、300行目が実体カーソル（点滅の止まるカーソル）になっていればわかるのですが、100行目のままです。なので、基点が「実体カーソルの位置」から外れているような感じがあります。
ただ、
> 別のアプローチとして、マルチカーソル時の [貼り付け] 処理について、他の編集操作と同様のスクロール挙動にそろえることで、スクロールの乱れをある程度抑えられるかもしれません。
>
> (いただいた表の 1 枚目、2 枚目の「貼り付け」のケースを「直接入力」と同じ挙動にするイメージです）「貼り付け」が「直接入力」と同じ挙動になるということで、こちらで要望が満たされると思われます。
> > 基点が画面内の状態で編集したとき、スクロールしない
> > マウススクロールによって実体カーソル表示位置が基点表示位置から外れたとき、そこを新たな基点表示位置とし、スクロールしないようにします。> 現在の仕様では「編集が行われたとき」に基点が更新されるため、IME 変換中の未確定状態では基点が更新されず、その結果スクロールが発生してしまう、という流れになります。
>
> これに対応するには、「日本語入力の開始時」に基点を更新する必要があります。
>
> ただしこの場合、IME 入力をキャンセルしても基点だけが更新されてしまうことになるため、その点はある程度の妥協が必要になりそうです。日本語入力のキャンセルは、直接入力や 単一カーソル時の[貼り付け] を [やり直し] するのと変わらないように思います。
それらも基点は更新されていますが、スクロールしないため自然な動作に感じられます。（ちなみに、[変換中の文字列を挿入モードで入力する] 有効 + 選択範囲がある + 単一カーソル編集のときは、直接入力と同じ挙動となり、基点が更新されます）
とはいえ、マウススクロールしなければ気付かない範囲で私の要望外なので、こちらはお任せします。
（合わせたほうがまとまっていいような気がしての提案でした）> ともあれ、今回いただいたご提案や検証結果をもとに、次回バージョンで試験的に新しい仕様を実装してみたいと思います。
>
> かなり複雑な仕様になりそうですが、まずはかたちにしてみて、実際の使い心地を確認しながら調整していけたらと思います。次回バージョンで…！
要望したものの、さっそく組み込んでいただけるとなると嬉しさこの上ないです。うまく仕様がはまって試験導入が良い結果につながることを願っております。
どうぞよろしくお願いいたします。| nimx | 返信 -
ご返信ありがとうございます。
> お調べくださった情報も合わせて、基本的にタイプライタースクロールとマルチカーソルは相容れない機能で、Meryが文字入力に対応していることが特別な状態だったんですね。
Mery としてもそこまでは想定していなかったのですが、たまたま大きな違和感なく動いていただけのようですね。カーソル位置の奪い合いが起きてもおかしくない場面なのに… ^^;
> 次のような認識だったのですが、ここが違っているのかもしれません。
> 「基点を○○に更新する」とは、○行○列といった文書内の位置を主に指す（表示位置が含まれることもある）そのご認識で合っています。
> 「基点を○○に移動する」とは、画面中央といった画面内の表示位置を指す
こちらも正しい認識です。
> 具体的には、カーソルが 文書の100行目（実体）・200行目・300行目にある場合
>
> [貼り付け] を行うと、300行目が画面下部に表示されます。このとき、内部的には実体カーソルを 100 行目 → 200 行目 → 300 行目の順に移動させながら、1 箇所ずつ処理を行っています。
そして、300 行目の処理が終わった時点では、実体カーソルが 300 行目にあり、タイプライタースクロールの基点もその時点の状態 (300 行目が画面下部に表示された状態) に更新されます。(表 1 のとおりです)
ただしその後、マルチカーソルの仕様により、処理前の実体カーソルを復元するため、最終的に実体カーソルは 100 行目に戻ります。このとき、タイプライタースクロールの基点は更新されません。
> ここで マルチカーソルを解除・左右キーでのカーソル移動・入力文字を確定といった操作を行うと、100行目が画面下部に表示されます。
> 1のとき、300行目が実体カーソル（点滅の止まるカーソル）になっていればわかるのですが、100行目のままです。なので、基点が「実体カーソルの位置」から外れているような感じがあります。タイプライタースクロールの基点は 300 行目の処理が終わった状態 (画面下部) に更新されていますが、実体カーソルは 100 行目に戻っています。
この状態でマルチカーソルを解除すると、100 行目が画面下部に表示されることになります。
> 「貼り付け」が「直接入力」と同じ挙動になるということで、こちらで要望が満たされると思われます。
ある程度はご希望に近い挙動になるかと思いますが、前述のとおり既存の仕様と干渉してしまう部分があるため、「貼り付け」と「直接入力」で完全に同じ動作にはならない可能性があります。
無理やり合わせるとすれば、
- 実体カーソルを 100 → 200 → 300 行目へ順に移動して各箇所を処理
- マルチカーソル仕様により、実体カーソルを 100 行目へ復元
- その後にタイプライタースクロールの基点を再度 100 行目に更新
…というような対応になるかもしれませんが、ちょっと無理やりすぎる気も…。
> 日本語入力のキャンセルは、直接入力や 単一カーソル時の[貼り付け] を [やり直し] するのと変わらないように思います。
> それらも基点は更新されていますが、スクロールしないため自然な動作に感じられます。
>
> （ちなみに、[変換中の文字列を挿入モードで入力する] 有効 + 選択範囲がある + 単一カーソル編集のときは、直接入力と同じ挙動となり、基点が更新されます）なるほど、たしかに [変換中の文字列を挿入モードで入力する] が有効な場合は、直接入力と同じような動作になります。
ただ、[変換中の文字列を挿入モードで入力する] が無効の場合は、単一カーソル編集でも基点は更新されず、スクロールが発生します。
また、[変換中の文字列を挿入モードで入力する] が有効の場合でも、マルチカーソル編集中は一時的に無効化されるため、同じく基点は更新されず、スクロールが発生します。
> とはいえ、マウススクロールしなければ気付かない範囲で私の要望外なので、こちらはお任せします。
ありがとうございます。こちらについては、それほど難しい実装にはならなさそうなので、対応する方向で検討してみますね。
> うまく仕様がはまって試験導入が良い結果につながることを願っております。
ご協力ありがとうございます。
まずは実際に実装してみないことには始まりませんので、ひとまずこの仕様で進めてみますが、マルチカーソルでの「貼り付け」との干渉については、もう少し検討が必要になりそうですね ^^;
| Kuro | 返信 -
> Mery としてもそこまでは想定していなかったのですが、たまたま大きな違和感なく動いていただけのようですね。カーソル位置の奪い合いが起きてもおかしくない場面なのに… ^^;
私個人としてはラッキーでした (^^
おかげでタイプライタースクロールを実用的に活用できております。> こちらについては、それほど難しい実装にはならなさそうなので、対応する方向で検討してみますね。
まず日本語入力について、前向きにご検討くださりありがとうございます。
マルチカーソル編集については、認識がおおむね合っていて良かったです。
> マルチカーソル編集時には、基点を「実体カーソルの位置」とする
先立って提案させていただいたこちらは、編集時だけでなく編集後も含めた希望となっていたため、かみ合わなかったのですね。
> 無理やり合わせるとすれば、
>
> 1. 実体カーソルを 100 → 200 → 300 行目へ順に移動して各箇所を処理
> 2. マルチカーソル仕様により、実体カーソルを 100 行目へ復元
> 3. その後にタイプライタースクロールの基点を再度 100 行目に更新
>
> …というような対応になるかもしれませんが、ちょっと無理やりすぎる気も…。端から見ると問題ないと思われるのですが、無理矢理すぎますか。
現行の直接入力では、入力が各所へ反映されつつ、基点は100行目を維持しているかのような動きですが、これは上記の 1 ～ 3 とは異なる処理手順なのでしょうか。
また、タイプライタースクロールを無効にしている場合（表 2 ）でも、元の実体カーソルを基点に画面表示される方が、より直感的だと思います。
タイプライタースクロールの有無は関係なく、マルチカーソルで [貼り付け] を行った際の仕様として変更するのはいかがでしょうか。
ご検討いただければ幸いです。
| nimx | 返信 -
ご返信ありがとうございます。
> 私個人としてはラッキーでした (^^
私のほうはまったく意識していなかった部分だったので、「やべっ」と思いましたが、思ったよりも深刻な競合はなさそうで、結果的にラッキーでした ^^;
> 現行の直接入力では、入力が各所へ反映されつつ、基点は100行目を維持しているかのような動きですが、これは上記の 1 ～ 3 とは異なる処理手順なのでしょうか。
はい、こちらは別の処理手順になっています。
「直接入力」や「削除」といった基本的な操作の場合、入力される文字がすべてのカーソルで共通になるため、上記の 1 ～ 3 のような処理手順は踏んでおらず、実質的にほぼ同時編集が可能な仕組みになっています。(つまり、スクロールや各カーソル位置での基点の更新は発生しません)
一方、「貼り付け」については、同じ文字列が貼り付けられるケースもありますが、複数の選択範囲をコピーして、それぞれに対応する文字列を貼り付けることも可能です。
このような仕様のため、「直接入力」のような同時編集の仕組みは使えず、実際には上から順にカーソル位置へ貼り付けていく、いわば「手動操作」を内部的にシミュレートすることで実現しています。
これが、1 ～ 3 の処理手順です。
> また、タイプライタースクロールを無効にしている場合（表 2 ）でも、元の実体カーソルを基点に画面表示される方が、より直感的だと思います。
>
> タイプライタースクロールの有無は関係なく、マルチカーソルで [貼り付け] を行った際の仕様として変更するのはいかがでしょうか。おっしゃるとおりです。これについては、前回お伝えした、
> 別のアプローチとして、マルチカーソル時の [貼り付け] 処理について、他の編集操作と同様のスクロール挙動にそろえることで、スクロールの乱れをある程度抑えられるかもしれません。
↑ という方法で、ある程度改善できるかと思います。
ただ、前述のとおり [貼り付け] の内部処理上、「直接入力」のような同時編集が適用できない事情があります。
そういうわけで、その後もいろいろと検討していたのですが、無理やり感を抑えつつ、他のケースにも応用できそうな仕様を思いつきました。
> 無理やり合わせるとすれば、
>
> 1. 実体カーソルを 100 → 200 → 300 行目へ順に移動して各箇所を処理
> 2. マルチカーソル仕様により、実体カーソルを 100 行目へ復元
> 3. その後にタイプライタースクロールの基点を再度 100 行目に更新
>
> …というような対応になるかもしれませんが、ちょっと無理やりすぎる気もするので、ここはもう少し検討が必要になりそうです…。ここまでは、前回お話しした内容ですね。
そこで、挙動をできる限り「直接入力」に近づけるための新たな案として、「基点の更新を一時的に停止できるロック機構」を導入する方法を考えてみました。
処理の流れは、こんな感じになります。
- マルチカーソルで [貼り付け] を実行
- 基点更新をロック (このタイミングで、基点を実体カーソルの位置に更新)
- ここから従来の処理 (ロック中なので基点の更新は発生しない)
- 実体カーソルを 100 → 200 → 300 行目へ順に移動して各箇所を処理
- マルチカーソル仕様により、実体カーソルを 100 行目へ復元
- ここまで従来の処理 (ロック中なので基点の更新は発生しない)
- 基点更新のロックを解除
このようにすれば、貼り付け前の実体カーソル位置 (= 基点) を保持したまま、処理を完了させることができそうです。
また、このロック機構を導入しておけば、今回は [貼り付け] のための対応ではありますが、今後、同様の問題が他のコマンドでも発生した場合に、より柔軟に対処できるようになるかと思います。
ちなみに、[貼り付け] 以外でも同じような問題が起こる可能性はありますが、すべてのコマンドを網羅的にチェックするのはなかなか大変なので、ベータ版でのフィードバックを通じて、その都度、必要に応じて対応していければと思います。
| Kuro | 返信 -
> 私のほうはまったく意識していなかった部分だったので、「やべっ」と思いましたが、思ったよりも深刻な競合はなさそうで、結果的にラッキーでした ^^;
そんな心境でしたか (笑
結果的にお互いラッキーだったようで何よりです。> 「直接入力」や「削除」といった基本的な操作の場合、入力される文字がすべてのカーソルで共通になるため、上記の 1 ～ 3 のような処理手順は踏んでおらず、実質的にほぼ同時編集が可能な仕組みになっています。(つまり、スクロールや各カーソル位置での基点の更新は発生しません)
>
> 一方、「貼り付け」については、同じ文字列が貼り付けられるケースもありますが、複数の選択範囲をコピーして、それぞれに対応する文字列を貼り付けることも可能です。
>
> このような仕様のため、「直接入力」のような同時編集の仕組みは使えず、実際には上から順にカーソル位置へ貼り付けていく、いわば「手動操作」を内部的にシミュレートすることで実現しています。なるほど、「直接入力」などと「貼り付け」の質の違いがわかりました。
あまり意識してなかったのですが、コピー元とペースト先のカーソル数を同一にすると、それぞれに対応して貼り付けられますね。
それに伴った仕様の違いも把握いたしました。
詳しく教えていただきありがとうございます。> そこで、挙動をできる限り「直接入力」に近づけるための新たな案として、「基点の更新を一時的に停止できるロック機構」を導入する方法を考えてみました。
> このロック機構を導入しておけば、今回は [貼り付け] のための対応ではありますが、今後、同様の問題が他のコマンドでも発生した場合に、より柔軟に対処できるようになるかと思います。
新案、拝見しました。たくさん考えていただいてありがとうございます。
今後のためにもなっているのがいいですね。ひとつ疑問があるのですが、[貼り付け] で実体カーソルの行が変わる場合はどうなるでしょうか。
例えば、コピー元に改行を含んでいて 101 行目に変わったり、折り返し表示で物理行が変わる場合です。もしこれで基点が 100 行目のままならば、少し違和感が残ります。
（現在の挙動と比較すると僅かなものですが）> 2. 基点更新をロック (このタイミングで、基点を実体カーソルの位置に更新)
>
> - ここから従来の処理 (ロック中なので基点の更新は発生しない)
> 3. 実体カーソルを 100 → 200 → 300 行目へ順に移動して各箇所を処理対処法としては、こちらを次のようにするくらいしか思いつかず……。
- 100 行目だけ（元の実体カーソルの位置だけ）処理し、基点更新をロック
- 200 → 300 行目と処理していく。
こちらの方がよっぽど無理矢理ですね (^^;
| nimx | 返信 -
ご返信ありがとうございます。
> ひとつ疑問があるのですが、[貼り付け] で実体カーソルの行が変わる場合はどうなるでしょうか。
> 例えば、コピー元に改行を含んでいて 101 行目に変わったり、折り返し表示で物理行が変わる場合です。
>
> もしこれで基点が 100 行目のままならば、少し違和感が残ります。なるほど、その違和感はよくわかります。でも結論から言うと、その点は大丈夫です。
ちょっと文章だけで説明するのが難しいのですが、前回ご説明した仕組みのままで、コピー元に改行が 1 つだけ含まれていて、[貼り付け] のあとにカーソルが 101 行目に移動するケースを例にしてみますね。
- マルチカーソルで [貼り付け] を実行
- 基点更新をロック (このタイミングで、基点を実体カーソルの位置に更新)
→ たとえば 100 行目が画面の一番上にあれば、基点は「1」でロックされます。
- ここから従来の処理 (ロック中なので基点の更新は発生しない)
- 実体カーソルを 100 → 200 → 300 行目へ順に移動して各箇所を処理
- マルチカーソル仕様により、実体カーソルを 101 行目へ復元
→ 改行が入ったぶんだけ、1 行下にずれた感じですね。
- ここまで従来の処理 (ロック中なので基点の更新は発生しない)
- 基点更新のロックを解除
という流れになるので、結果的には…
- 実体カーソルは 101 行目
- 基点は「1」のまま
となり、[貼り付け] 後は画面の一番上に 101 行目が表示されている状態になります。
ここでのポイントは、「実体カーソルの位置」をロックするのではなく、「タイプライタースクロールの基点」をロックしているということです。
(タイプライタースクロールの性質上、「基点」さえ更新されなければ、実体カーソルが移動することによる影響はないため)
ちなみに、単一カーソルで改行を含む貼り付けを行った場合でも、タイプライタースクロールの基点は動かないようになっています。
| Kuro | 返信 -
丁寧にご説明くださったおかげでようやく理解できました。
ありがとうございます！文書内の位置と画面内の位置、どちらを指しているのか正しく判断できておらず、お手数をおかけしました。
「直接入力」などとは異なる処理方法ですが、使用感が似たものになることもわかりました。
> カーソルが画面外の状態で編集したとき、基点を「画面中央」にしない
> → Scrivener 風の「画面中央へスクロールする」仕様は廃止し、基点を維持するようにします。前出のこちらと合わせて、あらためて実装をお願いいたします。
実装の際や、何かありましたら、フィードバックさせていただきます。快適 Mery ライフに拍車がかかりそうで楽しみです (^^
| nimx | 返信 -
更新作業お疲れさまです。
さっそく、ひと通り試してみました。
もちろん確認済みでしょうが、こちらでも特に問題はありません。スクロール位置がぴたっと安定して見やすく、とても快適になりました。
マウスへの切り替えが減るので作業が楽になりそうです。マウススクロール時の動作もまとまって、いい感じです。
丁寧にご対応くださり、どうもありがとうございました (^^
| nimx | 返信 -
早速お試しいただき、ありがとうございます。
> もちろん確認済みでしょうが、こちらでも特に問題はありません。
動作確認はできるだけしているものの、リリースのたびに緊張でゲボボボボ…となっております。
ひとまず問題なさそうとのことで、ほっとしました。
> スクロール位置がぴたっと安定して見やすく、とても快適になりました。
> マウスへの切り替えが減るので作業が楽になりそうです。そう言っていただけると嬉しいです。
とはいえ、あまり自信があるわけではなく…今回かなり大きな仕様変更でしたので、また何かお気づきの点がありましたら、ぜひ教えていただけると助かります ^^
| Kuro | 返信
