ペインをまたぐ移動
-
画面分割をして利用した場合、右(上)ペインでカーソルを移動すると、左(下)ペインでもそれが反映されてしまって、左ペインに戻った時に右ペインで移動したカーソル先に飛んでしまいます
右ペインと左ペインでカーソル位置を別々に記憶する設定はないのでしょうかまた、現在自分がどのペインに居るのか分かりづらいのはどうにかならないでしょうか
| かずら | 返信 -
> 右ペインと左ペインでカーソル位置を別々に記憶する設定はないのでしょうか
現在のところそういった設定はありません。ご意見は今後の開発の参考にさせて頂きたいと思います。
> また、現在自分がどのペインに居るのか分かりづらいのはどうにかならないでしょうか
[ツール] メニューの [オプション] から [表示] カテゴリの中の設定で、[カーソル] と [カーソル (IME 有効)] でカーソルの色を変更することができますので、目立つ色にしておけばどちらのペインにカーソルがあるか分かりやすくなるのではないでしょうか。
| Kuro | 返信 -
> > また、現在自分がどのペインに居るのか分かりづらいのはどうにかならないでしょうか
> [ツール] メニューの [オプション] から [表示] カテゴリの中の設定で、[カーソル] と [カーソル (IME 有効)] でカーソルの色を変更することができますので、目立つ色にしておけばどちらのペインにカーソルがあるか分かりやすくなるのではないでしょうか。
それはやっているのですが、両方ともカーソルが表示外の場合はわかりません
また、カーソルそのものも小さいため、ぱっと見でわかりません
せめて1キャラ分でブリンクしてくれればとは思います| かずら | 返信 -
カーソルの幅ですが、画面上から変更できませんが、Mery.ini に設定値を直接書けば変更可能となっています。
Mery.ini の編集は Mery を終了 (常駐している場合は常駐も終了) させた状態で、Mery.ini をメモ帳などの Mery 以外のエディタで編集します。
[Display] セクションに CaretWidth、ImeCaretWidth という項目を追記して、設定値を十分に大きな数値にすれば、カーソルの幅がフォントの平均幅のサイズになります。
[Display] CaretWidth=100 ImeCaretWidth=100
Mery.ini は、以下の場所にあると思います。
C:\Users\<ユーザ名>\AppData\Roaming\Mery\Mery.ini現状ではこれぐらいしか対応方法がありませんが、ご了承ください。
| Kuro | 返信 -
> [Display] セクションに CaretWidth、ImeCaretWidth という項目を追記して、設定値を十分に大きな数値にすれば、カーソルの幅がフォントの平均幅のサイズになります。
有難うございます
この設定探してたんですけど、オプションからは設定できなかったんですね
このサイズで慣れ親しんでいたから、今の細いやつは辛かった| かずら | 返信 -
> 画面分割をして利用した場合、右(上)ペインでカーソルを移動すると、左(下)ペインでもそれが反映されてしまって、左ペインに戻った時に右ペインで移動したカーソル先に飛んでしまいます
ペインはあくまで一つの文書に複数の描画範囲(窓)を開けてるだけと考えれば納得できるのでは。
しかしPgUp/PgDnの動作に分岐があるみたいなので、それで混乱する可能性も。
・通常動作はキャレット(編集点)を基準にして描画幅分”キャレット”が移動するが
・キャレットが移動方向と反対の描画範囲外にある場合、現在の描画範囲内に仮のキャレットを設定し、それを基準に移動してるような動作。→これが一見ペインのスクロールに見える要因?。| MM | 返信 -
> ペインはあくまで一つの文書に複数の描画範囲(窓)を開けてるだけと考えれば納得できるのでは。
マウスをクリックしてペイン移動するなら、それでもなんの問題もないんですけど、キーボードだけで完結させようとすると飛んじゃうんですよね
マクロにショートカットを設定しだすと、マウスに手を伸ばすのが億劫になってしまってw
折角の機能なんだから、最大限に利用したいんですよ
使えば使うほど、不満が出てくるってやつです
重箱の隅をつつくタイプなのでw自分が今何処のペインに居るのかがわかれば、マクロにでも組み込んでなんとかなるかも知れませんが
ざっと見た感じ、見当たらなくて……
右ペインなのか左ペインなのかアウトプットバーなのかなどなど| かずら | 返信 -
>> かずら さん、MM さん
ご意見ありがとうございます。
ぐふ。本日すべて開発に費やしました結果、これはちょっと…
MM さんのおっしゃる通り、Mery の分割窓は 1 つの文書に別の閲覧窓を開けてるだけという簡易なものです。
キャレット位置と選択範囲を窓ごとに持ち、編集の都度、両方の窓でそれぞれ異なるキャレット位置と選択範囲を維持し、なおかつマルチカーソルにも対応させる必要があるということで、かなり絶望的な開発難易度な気がしてきました。
でも、Visual Studio Code とか Sublime Text だと実現できているようなので、何か妙案というか、こんな技が!みたいなテクニックがあったりするのかもしれません。
ちなみに…
・サク〇エディタさん
→ 選択範囲は維持されるけど、編集すると他の窓の選択範囲はズレる・秀〇エディタさん
→ 選択範囲は維持されるけど、編集した内容が他の窓にリアルタイムでは反映されず、フォーカスを別の窓に移動すると反映される。一応、マルチカーソルと選択範囲は維持される・E〇Editor さん
→ 選択範囲は維持されるけど、編集すると他の窓の選択範囲やマルチカーソルはすべて解除される・Visual Studio Code
→ 編集しても両方の窓で選択範囲が維持される。マルチカーソルで編集したときのみ、他の窓の選択範囲が解除され、現在編集中の窓の選択範囲と同じになる・Sublime Text
→ 編集しても両方の窓で選択範囲が維持される。マルチカーソルで編集しても他の窓でマルチカーソルの選択範囲が維持される。これ最強・Visual Studio 2019
→ 編集しても両方の窓で選択範囲が維持される。マルチカーソルで編集しても他の窓でマルチカーソルの選択範囲が維持される。マイクロソフトの本気まだ諦めたわけではないので、技術的なアイデアや情報などございましたらご協力いただけると助かります。
正攻法でやるならマルチカーソル機能×2 みたいな設計で、マルチカーソルを根本から作り直す必要がありそうですが…😅
| Kuro | 返信 -
もし"自分"ならですが
案1 フォーカスのないペイン(Notエディター単位)の背景色の設定を新設
案2 「逆タイプライタースクロールモード」
キャレット移動(イベント)時に
・キャレット位置がカレントペイン幅±数行を越えてるなら、キャレット自動移動(選択範囲等は解除)。ここら辺ならできるかもという感じで、ちょっとマルチカーソルとかは頭が追い付きませんね。
| MM | 返信 -
> キャレット位置と選択範囲を窓ごとに持ち、編集の都度、両方の窓でそれぞれ異なるキャレット位置と選択範囲を維持し、なおかつマルチカーソルにも対応させる必要があるということで、かなり絶望的な開発難易度な気がしてきました。
あーナルホド、そこまで考えてませんでした> ・秀〇エディタさん
伏せ字になってねぇwww> まだ諦めたわけではないので、技術的なアイデアや情報などございましたらご協力いただけると助かります。
引退プログラマーの今の作法を全く知らないおっさんから言わせてもらえば、全部の変数をpush/pop(swapの方がいいか?)すればいいだけじゃね
配列にして0番と1番にすればいいだけじゃね
って考えちゃいます
自分、アセンブラとベーシックしか書いたことないものでwそもそも異なる文章を編集して、それぞれにカーソル位置や選択範囲を記憶するベースは出来てるんです
後は単純に「編集している文章が同じタブ」が二枚あるって想定すればいいだけではないでしょうか
選択位置だのカーソル位置だのの同期が微妙に面倒そうですが
その辺はマーク位置の保持で下地ができてると思います
編集して別ペインのカーソルや選択の位置ずれは、都度ずらせばいけるんじゃないかなーと自分としては、カーソル位置さえあっていれば、選択は解除されててもいいやって感じです
| かずら | 返信 -
ご意見ありがとうございます。
>> MM さん、かずら さん
なるほど、技術的に可能な範囲でとなると 案1 はアリですね。
案2 のほうは、ご要望の内容とは反することになってしまいますが、カーソル位置を見失うという問題は解決されそうですね。
現在フォーカスがあるコントロールを目立たせるという仕組みについては、こんなソフトがありました。
https://www.vector.co.jp/soft/dl/winnt/writing/se082089.html
↑ IME オンのときだけですが、現在フォーカスがあるコントロールに枠線をつけてくれるアプリで、Mery で試してみたらちゃんとそれぞれのペインに枠線が付きました。>> かずら さん
> あーナルホド、そこまで考えてませんでした
私も、いざ開発に挑戦してみて気づきました。「あー、これ無理なやつや…」と。
> 配列にして0番と1番にすればいいだけじゃね
> 編集して別ペインのカーソルや選択の位置ずれは、都度ずらせばいけるんじゃないかなーと正攻法だとそうなりますね。おっしゃる通り、その "微妙に面倒そうな同期" が最大の難関です。
選択範囲が 1 つだけならその方法で実装できそうだったのですが…
片方の窓でマルチカーソルで複数選択した状態のまま別の窓に移動して、そちらの窓でもマルチカーソルで複数選択して編集した場合、もとの窓のマルチカーソルの選択範囲を維持したまま編集を反映させるとなると、マルチカーソル×2 という想像したくない計算が必要となり、ウアァァァ!となった次第です。
> 自分としては、カーソル位置さえあっていれば、選択は解除されててもいいやって感じです
マルチカーソルがなければ行けそうなのですが、マルチカーソルを考慮すると、カーソル位置だけにしても、やはりガチで開発するしかなさそうです。
しばらく時間がかかりそうな案件ですが、他の国産テキストエディターではきちんと実装できていない機能ということで、やる気は出てきましたw
| Kuro | 返信 -
プラグインの方でペインのフォーカスイベントが掴めればプラグインの方での糸口になりそうかと調べてみました(ちょっと気になって)。
しかしやり方が悪いのか、まともにイベントを拾えませんでした(というよりNotePadはWinメッセ定数系は発火しない?)。45082=$B01A, 45083=$B01B あたりがペインのフォーカスイベントかな?
5156 =$1424も怪しい。
ここら辺の、あのドキュメントとかソースのこことかよっしゃ教えてもえーよという奇特な方が居れば...(そこまで知りたい訳じゃないんですが!調べた方法はDelphi pascal?で
EnumChildWindowsで'TNotePadEx'のペイン取得し
SetWindowLong(Pane, GWL_WNDPROC, NativeInt(@ProcPane) );で
イベントプロシージャをラップして(サブクラス化?)、
受信したイベントをMeryのアウトプットペインで直接見るというもの。プラグインを実際に作るとしたら
タブや上下左右のサブペインでペイン'TNotePadEx'が増減したときにサブクラス化の登録や抹消が必要なので、更にめんイベ色々調べる必要があるでしょう。(マクロAPIの方に縦書きのONOFF状態を知るプロパティが欲しいです(値はREADONLY、空のSETTERでいいので))
| MM | 返信 -
>> MM さん
ご協力ありがとうございます。気になりますよね。
フォーカス時のイベントですが、Visual Studio の Spy++ でメッセージを確認してみたところ、TNotePadEx でも WM_SETFOCUS、WM_KILLFOCUS イベントは発生しているようですよ。
> 45082=$B01A, 45083=$B01B あたりがペインのフォーカスイベントかな?
> 5156 =$1424も怪しい。45082, 45083 が飛んできているのも見えましたが、これは謎です。
5156 (WM_USER + $1024) は Mery 専用のイベントで、エディター部にフォーカスが設定されたときと解除されたときに発生します。設定時と解除時、どちらも同じメッセージなので判別はできませんが…。
> タブや上下左右のサブペインでペイン'TNotePadEx'が増減したときにサブクラス化の登録や抹消が必要なので、更にめんイベ色々調べる必要があるでしょう。
そうですね。アクティブなペインに枠線をつけるということでしたら、前回の返信のときに紹介させていただいた aimemon というソフトで実現できているのですが、ソースコードも付属しているようなので、技術的には Mery のプラグインでも実現可能だと思います。
> マクロAPIの方に縦書きのONOFF状態を知るプロパティが欲しいです(値はREADONLY、空のSETTERでいいので)
そうですね、現在のところプラグインからは取得可能ですが、マクロからも取得できる何らかの仕組みを検討してみたいと思います。
>> MM さん、かずら さん
ここからは余談です。
私もその後、別窓でそれぞれカーソル位置と選択範囲を維持する仕組みについて検討しましたので現状報告ですが、新たな問題が 2 つ出てきました。
【問題1】 矩形選択
2 つの窓で別々に矩形選択を維持するのが困難。
【問題2】 [元に戻す] や [やり直し] の操作
2 つの窓にそれぞれカーソル位置を持たせるとして、その場合、[元に戻す] の操作を行ったときに、それぞれの窓で異なるカーソル位置を復元しなければなりません。
となると、それぞれの窓で別々に操作履歴を保持する必要があり、Undo データを 2 つ用意して別々に管理しなければならなくなります。
しかも復元するときは、別の窓で行った操作も考慮しないといけないので、2 つの Undo データを組み合わせて、過去の状態を復元しなければならず、しかも現在 [元に戻す] の操作を行っている窓と、過去に編集を行った窓が異なる場合は整合性がとれない気がします。
そこで、改めて他のエディターの仕様を確認してみたところ…
・サク〇エディタさん
× 矩形選択 → 編集を行うと別窓の選択範囲は固定なのでどんどんズレていく
× 元に戻す → [元に戻す] もどんどんズレていく (別窓の選択範囲は履歴を持たない)・秀〇エディタさん
〇 矩形選択 → 別窓で編集してもある程度維持される
× 元に戻す → [元に戻す] で選択範囲は復元されない (別窓の選択範囲は履歴を持たない)・E〇Editor さん
× 矩形選択 → 別窓で編集すると解除される
× 元に戻す → 編集や [元に戻す] を行うと、別窓の選択範囲は解除される (別窓の選択範囲は履歴を持たない)・Visual Studio Code
〇 矩形選択 → 矩形選択は正確には矩形ではないが、マルチカーソルとして維持される
△ 元に戻す → [元に戻す] を行うと、別窓の選択範囲はある程度維持される。別窓で操作履歴を持っているわけではなく、現在の窓の Undo データをもとに別窓の選択範囲を再計算しているようで、実際の操作履歴とは異なる選択範囲が復元されることもある・Sublime Text
〇 矩形選択 → 矩形選択は正確には矩形ではないが、マルチカーソルとして維持される
〇 元に戻す → [元に戻す] を行うと、別窓の選択範囲も過去の状態が完全に復元される。別窓で個別に操作履歴を管理している模様。完璧です。・Visual Studio 2019
〇 矩形選択 → 矩形選択は正確には矩形ではないが、マルチカーソルとして維持される
△ 元に戻す → Visual Studio Code と同様・Notepad++
〇 矩形選択 → 別窓で編集してもある程度維持される
△ 元に戻す → Visual Studio Code と同様という結果でした。
理想的なのは Sublime Text のように窓ごとに操作履歴を持つ方式ですが、操作履歴のデータ量が 2 倍になりますし、別窓にそこまでの機能は求められていないような気もします。
そういうわけで、Visual Studio Code のような方式、つまり、矩形選択はマルチカーソルに変換して維持。[元に戻す] は Undo データを窓ごとには持たず、現在の窓の Undo データから再計算して別窓の状態をある程度は復元できる、という感じなら実現できるかもしれません。
とりあえずこんな仕様で開発を進めてみようと思います。
| Kuro | 返信 -
WM_*系普通に発生してたとは! 自分のやり方がまずかったか。
WM_USER、WM_APPなるWin指針があるとは知りませんでした。
メッセージ45082, 45083についてですが
エディタエンジン独自のメッセージじゃないなら、そりゃどっか派生元のオブジェクトのですよね(汗
真魚のソース見た時点で気付くべきでした(苦笑
TPageControl > ... > TWinControl 最後のやつのファイルVcl.Controls.pasの中で
CM_BASE = $B000; // = 45056
CM_ENTER = CM_BASE + 26; // = 45082
CM_EXIT = CM_BASE + 27;
とありました。すいませんでした!> 5156 (WM_USER + $1024) は Mery 専用のイベントで、エディター部にフォーカスが設定されたときと解除されたときに発生します。設定時と解除時、どちらも同じメッセージなので判別はできませんが…。
おお!そうだったのですね。GetFocus()を混ぜればできそうではありますね。自分のは不味いですが。
Meryは画面分割機能を積極的に進めるベクトルとは思ってなかったので
作者氏のモチベがちょっと意外です(他の人の使用頻度もあまり...と感じてたし、現状で充分だとも思ってたので)。
画面分割を突き詰めれば別ウィンドウで同じ文書開く(ファイル変更検知後自動読込で実現できるが)のと変わらないのでそっちはないだろうなとwSublimeはちょっと驚きですね。マジですか。尋常じゃないですねw
履歴、内部的には1つだけど、窓ごとの識別子をつけてスルー+履歴データの再計算してるんじゃないでしょうか、もしかしたら。| MM | 返信 -
なるほど、45082 は Delphi のコントロールメッセージでしたか、勉強になりました。
> おお!そうだったのですね。GetFocus()を混ぜればできそうではありますね。自分のは不味いですが。
タイマーを使って定期的に GetFocus でフォーカスのあるコントロールを監視するという方法も考えられますね。美しくはなさそうですが。
> Meryは画面分割機能を積極的に進めるベクトルとは思ってなかったので
> 作者氏のモチベがちょっと意外です(他の人の使用頻度もあまり...と感じてたし、現状で充分だとも思ってたので)。そうなんですよね。TNotePad の作者様も画面分割機能は推奨してなくて、他の機能との相性が悪いということとメンテナンスが大変ということで、現在の TNotePad では機能が削除されています。
Mery でもマクロとの相性が悪いことや DirectWrite だと遅くなることもあって廃止したい機能のひとつですね。ご指摘の通り、使用頻度も低いようですし…。
そういうわけで、今回のモチベは「他の国産テキストエディターではきちんと実装できていない仕組み」という点の、技術的な好奇心からです (笑)
> Sublimeはちょっと驚きですね。マジですか。尋常じゃないですねw
> 履歴、内部的には1つだけど、窓ごとの識別子をつけてスルー+履歴データの再計算してるんじゃないでしょうか、もしかしたら。その可能性もありますね。
しかし、別窓がない状態で色々編集して、途中で別窓を表示してから [元に戻す] をすると、別窓のデータもちゃんと元に戻るんですが、どうやって再計算してるのか…、気になります。
データの Undo 情報と選択範囲の Undo 情報を別々に保持してるのかな。
| Kuro | 返信 -
> ご指摘の通り、使用頻度も低いようですし…。
え、そうなんですか?
昔ソース書いたりする時、重宝してたんですけど……
その時の癖なのか、今も常に2ペインで使ってます
時々3ペイン欲しくなるw
当時使ってたエディタは、分割したものを更に分割できたんですよね
だから上下分割した後、左右分割しようとしてできなかったときは、ちょっとショックでした
アウトラインとブクマがなかったら、困ってました| かずら | 返信 -
Mery は初心者向けのシンプルなテキストエディターをコンセプトにしているので、開発ツールのような機能はあまり人気がないですね。
最近は Visual Studio Code や、Atom、Adobe Brackets など、テキストエディターよりはちょっと重いけど統合開発環境よりは軽いという、"コードエディター" なるジャンルのソフトが人気を集めていて、ソースを書く人はそちらに移行されているようです。
いずれも無料ですし、Mery より多機能です。
確か、Visual Studio Code はいくつでも画面分割できたはずなので、試されてみてはいかがでしょうか?
| Kuro | 返信 -
> 確か、Visual Studio Code はいくつでも画面分割できたはずなので、試されてみてはいかがでしょうか?
ちょっと前までは、たまにiniを編集する程度でした
でも現状、ソースを書いているわけではなく、文章なのですよ
良さげなエディタを幾つか試したのですが、結局ここに戻ってきちゃいました| かずら | 返信 -
> > 右ペインと左ペインでカーソル位置を別々に記憶する設定はないのでしょうか
>
> 現在のところそういった設定はありません。ご意見は今後の開発の参考にさせて頂きたいと思います。3.1.0で、カーソル位置が保存されているのを確認しました
有難うございます| かずら | 返信 -
> しかし、別窓がない状態で色々編集して、途中で別窓を表示してから [元に戻す] をすると、別窓のデータもちゃんと元に戻るんですが、どうやって再計算してるのか…、気になります。
>
> データの Undo 情報と選択範囲の Undo 情報を別々に保持してるのかな。自分も無い頭と机上で考えてみましたが、先ず「編集履歴ストリームの途中の履歴を元に戻してみる」というところで躓いて出来ませんでした。
1回はできても、複数個行う、やった上で新しい編集の追加とかやり直しを考えると途端に情報量が増えて...orz自分が以前書いた履歴を「抜かす」というのはとっくにアホな回答だったと判ってたのですが、それ以上に無理と思いました。
そもそも根本的にはペインによって履歴を分類することをユーザーは求めてないと思うんです。
ユーザーが求めてるのは「近地点内の変更」のグループ化でしょうと!
過度の細分化は混乱しか生まないので、ペイン毎とするのが妥当というに過ぎない。
(それもペインを行ったり来たりして編集の順番が分からなくなるなど、ほんの稀ですよ!ええ!)ペインで区別すると編集範囲が重なる(別ペインの後方履歴の処理に困る)
...なら編集範囲が重なる履歴も「元に戻す」対象ストリームの一部と判断すればいいんじゃないか?
つまりそのペインの編集範囲に入る後方の履歴は別ペインでの編集だろうが「元に戻す」対象となると考えました。更に、対象となった履歴から現在の履歴位置までの履歴の範囲が重ならないなら
対象履歴を現在の位置まで移動してくることもできるのではないか?
(もちろん対象履歴も、そこまでの履歴群も移動によるズレを修正する必要はある、しかしそれだけ済む)
これによって前方は「元に戻す」列、後方は「やり直し」列という整列が守られる。[bkA0, bkA1, bkB0:"hello"追加, bkA2:"o"削除, bkA3, |doA4, doB1] = "hell"
ペインBで「元に戻す」
・bkB0が暫定対象。
・履歴位置|までを走査、bkA2がbkB0の影響範囲だったのでbkA2が暫定対象になり、続いてbkA3はbkA2の影響外だったので、bkA2が確定する。
[bkA, bkA1, bkB0, bkA3', | bkA2'=doA2, doA4, doB1] = "hello"前は"hell"追加に合わせ"o"位置の削除自体を失くす方向で悩んだが、"o"の削除を元に戻すにすればいいとなった。
新しい編集によって追加される履歴とそれによってクリアされる「やり直し」列についても
同様に「同一ペインである」という他に「追加履歴の範囲内」もクリア対象となる。
ただこの判定走査のとき、同一ペイン履歴破棄の影響を反映させながら別ペインの履歴が範囲内であるかが上手くいくのか自信が無い(比較範囲の拡大/縮小で済むのか分からないです)。以上なんですが、編集範囲の比較や履歴の順序を入れ替えるとか現実的なアプローチなのか...。
つまらないレスをした手前などから一応書きました。貴重な帯域を無駄にしてしまい申し訳ありません。| MM | 返信 -
コメントありがとうございます。
> 自分が以前書いた履歴を「抜かす」というのはとっくにアホな回答だったと判ってたのですが、それ以上に無理と思いました。
ナイスアイデア!と思いましたが、Sublime Text だと編集途中から別窓開いて、別窓でそれより以前の状態まで [元に戻す] ができていたので、やっぱり別の方法のようですね。
> そもそも根本的にはペインによって履歴を分類することをユーザーは求めてないと思うんです。
確かに、もともと今回のご要望でも履歴までは求められてませんね ^^;
> ユーザーが求めてるのは「近地点内の変更」のグループ化でしょうと!
なんぞ!?
> (それもペインを行ったり来たりして編集の順番が分からなくなるなど、ほんの稀ですよ!ええ!)
それは同意~。
> [bkA0, bkA1, bkB0:"hello"追加, bkA2:"o"削除, bkA3, |doA4, doB1] = "hell"
> ペインBで「元に戻す」
> ・bkB0が暫定対象。
> ・履歴位置|までを走査、bkA2がbkB0の影響範囲だったのでbkA2が暫定対象になり、続いてbkA3はbkA2の影響外だったので、bkA2が確定する。
> [bkA, bkA1, bkB0, bkA3', | bkA2'=doA2, doA4, doB1] = "hello"↑ すみません、この一連の操作がわからず、状況が把握できませんでした。めちゃくちゃ難易度高そうな…。bk って何を指すのでしょうか?
> 以上なんですが、編集範囲の比較や履歴の順序を入れ替えるとか現実的なアプローチなのか...。
文字の入力・削除ごとに発生する処理なので編集範囲の比較は負荷的に問題があるかもしれないですね。
あと、履歴データって変更行や保存行などのデータも保持しているので、履歴の順序入れ替えが発生するのはかなりやっかいです。
> つまらないレスをした手前などから一応書きました。貴重な帯域を無駄にしてしまい申し訳ありません。
いえいえ、貴重なご意見ありがとうございます。
「そもそも根本的にはペインによって履歴を分類することをユーザーは求めてないと思うんです。」というパワーワードは、開発の参考にさせていただきたいと思います。
| Kuro | 返信 -
> コメントありがとうございます。
こちらこそ私の駄文なぞを読んでいただきありがとうございます。のみならず種々の返答まで!> > [bkA, bkA1, bkB0, bkA3', | bkA2'=doA2, doA4, doB1] = "hello"
>
> ↑ すみません、この一連の操作がわからず、状況が把握できませんでした。めちゃくちゃ難易度高そうな…。bk って何を指すのでしょうか?すみませんテキトーに書いてしまって...、bk=backは「元に戻す」、doは「やり直す」の対象履歴で同じ履歴を表記代えしてるだけです。
ペインBの「元に戻す」なのにペインAの履歴が対象となり、履歴順序入れ替え bkA2⇔bkA3で、互いの座標が修正されるのでダッシュが付くだけです。
そもそも実現できるか計算してないし上の図もテキトーなんです、真面目に読まないで下さいお願いします!> 「そもそも根本的にはペインによって履歴を分類することをユーザーは求めてないと思うんです。」というパワーワードは、開発の参考にさせていただきたいと思います。
いえいえもっと言えば、ユーザーが求めているのは現在のカーソル位置の編集履歴です という無茶苦茶を言ってるだけなので...w
アウトライン的に第〇章の編集履歴は、この関数の編集履歴はとやるには人間能力的にも無理なのでペイン毎とするくらいが現実的ですと宣ってるだけです、その上で表面上そう動作しててもズレで済まない計算からは逃げますと。そのための言い訳です。| MM | 返信