行末改行含む1行選択時の挙動に関する要望
-
Kuroさん
開発お疲れさまです。
先日改善していただいたEditorConfigのおかげでだいぶ快適に過ごしています。ありがとうございました😊以下2点、1行選択に関する要望なのですが、お暇なときに吟味していただけると嬉しいです。
(1) 行番号クリックでの1行選択時のアクティブカーソル位置をファイル末尾側にしてほしい
行番号クリックでの1行選択時のアクティブカーソル位置をファイル末尾側にしてほしいです。
トリプルクリックでの行選択は末尾側がアクティブになる挙動なのですが、行番号クリック時には先頭側になるようです。ちなみに手元で確認できる範囲で見てみたところ、VSCode、サクラエディタ、NotePad++では上記要望と同じ動作になっていましたが、秀丸では先頭側にカーソルが置かれるようでした。
(2) 行番号クリック、またはトリプルクリック時に自動マーカーを効かせてほしい
最近のアップデートでは、選択範囲の末尾側が行頭にある場合には選択範囲末尾の行を対象外扱いとする仕様が広がりつつあると思います。
例: 複数行選択時のステータスバー上の行数表示、インデント／アンインデント、行の2重化そこで自動マーカーの機能においても、主に行番号クリック、またはトリプルクリック時に自動マーカーを効かせることを目的に、2行選択かつ選択範囲末尾側が行頭の場合においては自動マーカーを効かす仕様としてはいかがでしょうか？
時々、重複行を目視でさっと見つけたいときに使いたいことがありまして… (いや大人しく検索しなさいよ、と言われてしまう話ですが😅)
| yuko | 返信 -
EditorConfig、うまく動作しているようで安心しました😮💨
ご意見ありがとうございます。
> (1) 行番号クリックでの1行選択時のアクティブカーソル位置をファイル末尾側にしてほしい
VSCode を挙げられると弱いんですよねー。検討してみました。
> 秀丸では先頭側にカーソルが置かれるようでした。
なるほど、次のアクションで、方向キーでカーソルを移動したときのことを考慮されているのかもしれませんね。
秀丸エディタさん (または Mery) では、行番号をクリックして 1 行選択すると、カーソルはその行の先頭に移動しますが、その後↑/↓キーを押すと、きちんと 1 行上/下の行頭に移動します。
それに対して、末尾側にカーソルが来るエディターでは、同じ操作をすると、クリックした行番号より 2 行下の行頭に移動してしまいます。これはこれで、そういうものだと言われればそうなのかもしれませんが😅
Mery で「末尾側カーソル」を実装する場合、現状の仕様のままだと、選択状態からの↑/↓キーの仕様が秀丸エディタさんと同じなので、問題が生じます。
つまり、行番号をクリックして 1 行選択し、カーソルは末尾側 (次の行の行頭) に移動したとします。
続けて、↓キーを押すと、はじめにクリックした行番号の 2 行下に移動しますが、これは VSCode などと同じなので許容範囲とします。
問題は、↑キーを押したときで、このとき、本来は、はじめにクリックした行番号の 1 行上に移動してほしいところですが、カーソルは次の行の行頭にあるわけですから、そうはなりません。
ちなみに、VSCode では、きちんとはじめにクリックした行番号の 1 行上に移動します。Notepad++ は、この懸念事項をそのまま実装されているようですが…。
というわけで、「末尾側カーソル」を実装するためには、選択状態からの↑/↓キーの仕様も、VSCode 方式に変更する必要がありそうです。
> (2) 行番号クリック、またはトリプルクリック時に自動マーカーを効かせてほしい
これは対応しても良さそうですね。
ただし、他のエディターも確認しましたが、VSCode、Visual Studio 2022、Sublime Text、Notepad++、E〇Editor さん、いずれも行選択時にはマーカーの対象にならないようなので、何か問題があるのかなと不安は残りますが😱
| Kuro | 返信 -
なるほど。
私のなかでは行番号クリックは「行選択」というイメージだったため、それならばトリプルクリックと挙動が同じであるべきだと思ったわけですが、行番号クリックがやっていることは「行移動 兼 行選択」なのだと考えれば、アクティブカーソル位置はクリックした行番号のところにあるべきで、それゆえ今の挙動なのだと理解しました。> ちなみに、VSCode では、きちんとはじめにクリックした行番号の 1 行上に移動します。
えっ、そんな動きをしてたんだ！と驚き、私も見てみました。
どうやらVSCodeでは範囲選択をしている状態でのカーソル移動は以下の挙動をするようです。- Left: 範囲選択が解除され、先頭位置にカーソルが置かれる (現行Meryと一緒)
- Right: 範囲選択が解除され、末尾位置にカーソルが置かれる (現行Meryと一緒)
- Up: 範囲選択が解除され、先頭側の上の行にカーソルが置かれる
- Down: 範囲選択が解除され、末尾側の下の行にカーソルが置かれるなおこの動きはWindows 11のメモ帳でも同等でした。(Windows 10以下では未確認)
Left/Right だけでなく、 Up/Down も先頭/末尾が考慮されるとは知りませんでした。ただ、メモ帳では行頭クリック or トリプルクリックでの行選択からの下カーソルでは、行末位置から直下に行くようで、この場合にはVSCodeとは挙動が異なるようでした。(改行を含む行末尾、みたいな位置にカーソルが刺さってる？)
> > (2) 行番号クリック、またはトリプルクリック時に自動マーカーを効かせてほしい
>
> これは対応しても良さそうですね。ありがとうございます！仕様上問題なさそうであればぜひぜひお願いします。
| yuko | 返信 -
> 行番号クリックがやっていることは「行移動 兼 行選択」
そのようですね。このあたりはエディターコンポーネントの仕様なので、私が考えた仕様ではありませんが😅
秀丸エディタさんだと、行番号クリックの場合、先頭側にカーソルが来ますが、行番号をドラッグすると行選択モードになるようで、そのまま再び 1 行選択状態にすると、末尾側にカーソルが来るので、意図的にそういう仕様にしてそうですね。(Mery はそうなりません)
> ただ、メモ帳では行頭クリック or トリプルクリックでの行選択からの下カーソルでは、行末位置から直下に行くようで、この場合にはVSCodeとは挙動が異なるようでした。(改行を含む行末尾、みたいな位置にカーソルが刺さってる？)
これは謎仕様ですね。
私も、はじめは行末にカーソルが来るものだと思ったのですが、行頭の文字 (の左半分付近) をマウスでクリックしてカーソルを行頭に移動した状態で、行頭クリックで行選択したあとだと、カーソルが行頭位置から直下に移動するようです。バグなのかな。
とりあえず、Ver 3.6.2 で末尾側カーソルを実装してみたので、お試しくださいませ。
| Kuro | 返信 -
リリースした直後にバグを見つけてしまう現象が発生してしまいました😅
> - Up: 範囲選択が解除され、先頭側の上の行にカーソルが置かれる
> - Down: 範囲選択が解除され、末尾側の下の行にカーソルが置かれるVSCode 風の上記の動作を実装しようとしましたが、マウスで選択する際には問題ありませんでした。
しかし、キーボードで選択する際には、上下キーによる列の位置を保持する機能と干渉し、アクティブなカーソル側の列の位置に引っ張られてしまうようです。やだー、直したいー…😭
| Kuro | 返信 -
…と思ったら、Windows 11 のメモ帳や Visual Studio 2022 もアクティブなカーソル側の列の位置に引っ張られてました。
VSCode とメモ帳、どちらが正しいのか改めて検討が必要のようですね。
| Kuro | 返信 -
さっそく取り込んでいただいてありがとうございます！
自動マーカーは早速実戦投入する場面が多くなりそうです。> - Up: 範囲選択が解除され、先頭側の上の行にカーソルが置かれる
> - Down: 範囲選択が解除され、末尾側の下の行にカーソルが置かれるこちらについても、おおよそVSCodeやメモ帳と同等な感じになっているかと思います。(そもそもKuroさんがおっしゃてるように、VSCode、メモ帳の間で微妙に仕様が揺れていますが…)
それで上記周りの挙動を意識して少し使ってみたのですが、複数行選択から上記の動作になるの、この件に注意を引いた身で申し訳ないのですがちょっと使いづらいですね、、、なんだか大変申し訳ないです😥
特に、「スクロールするくらい多くの行数を選択 → コピー等の操作 → 選択解除がてら見えている位置 (アクティブカーソル) から上方向に移動しよう」ってケースにおいて、カーソルが選択範囲の上位置に移動ということになると想像以上に上に飛んでしまって、おっとっと…となってしまいました。
範囲選択からの左右キーの場合は「先頭方向／末尾方向」というイメージがあるためか違和感がないんですけどね。上下キーになるとある程度のページ遷移も兼ねる操作であるためか、なんだか使いづらい気がしました。(たぶん、同じ感想を抱いたのではないかと思っています)
個人的には、選択状態からの上下方向は以前の動作 (アクティブカーソル位置から素直に上下移動) が嬉しい感じでした。
| yuko | 返信 -
早速お試しいただきありがとうございます。
> そもそもKuroさんがおっしゃてるように、VSCode、メモ帳の間で微妙に仕様が揺れていますが…
そうなんですよね。その後、気づいたのですが Ver 3.6.2 の動作は、マウス、キーボードでの操作、ともに Visual Studio 2022 と同じでした。
> 範囲選択からの左右キーの場合は「先頭方向／末尾方向」というイメージがあるためか違和感がないんですけどね。上下キーになるとある程度のページ遷移も兼ねる操作であるためか、なんだか使いづらい気がしました。(たぶん、同じ感想を抱いたのではないかと思っています)
メモ帳、VSCode、Sublime Text、E〇Editor さんなど、モダンなエディターのほとんどはこの動作に準じているため、慣れれば違和感も薄れるかもしれません。
私は秀〇エディタさんで育った世代なので、この仕様はなかなか馴染めないと感じますが、VSCode に準拠という点では仕方ないのかなと思ったりもします。
> 個人的には、選択状態からの上下方向は以前の動作 (アクティブカーソル位置から素直に上下移動) が嬉しい感じでした。
これを従来の仕様に戻すとなると、行番号クリックでの行選択における末尾側カーソルも従来の仕様に戻さないと、整合性がとれなくなってしまいますね😅 (私の土日よ…)
それに、末尾側カーソルは戸惑われているユーザーさんもいらっしゃるようですし…。
【フォーラム】
https://www.haijin-boys.com/discussions/7538従来の仕様に戻しつつ、末尾側カーソルを実装するとなると、秀〇エディタさん方式。
つまり、行番号をクリックした場合は先頭側カーソルが適用され、行番号をドラッグして 2 行以上選択し、1 行に戻したときには末尾側カーソルが適用される、というのが正解なのかもしれませんね。
| Kuro | 返信 -
> メモ帳、VSCode、Sublime Text、E〇Editor さんなど、モダンなエディターのほとんどはこの動作に準じているため、慣れれば違和感も薄れるかもしれません。
おお、そうだったのですね。そう言われるとこの仕様が良い気がしてきました（単純）
そもそもが尖った独自仕様を追うことよりメジャーな動作＋αの位置付けを狙っているMeryですから、そういうことであれば私も異論ありません。
「アクティブカーソルでの選択解除は右カーソル」なイメージで、慣れたいと思います。
> これを従来の仕様に戻すとなると、行番号クリックでの行選択における末尾側カーソルも従来の仕様に戻さないと、整合性がとれなくなってしまいますね😅 (私の土日よ…)
そう、Kuroさんの可処分時間をめちゃくちゃ食ってしまったろうと思うと感想を言うのがはばかられました…が、前述の通り慣れの問題なのでしょうというところで、お聞き流しください。失礼しました🙇♂️
| yuko | 返信 -
> そもそもが尖った独自仕様を追うことよりメジャーな動作＋αの位置付けを狙っているMeryですから、そういうことであれば私も異論ありません。
選択範囲からの上下キーの仕様は、選択範囲基準なものと、カーソル位置基準なもの、どちらのエディターもあるので、どちらが独自仕様とも言えないところではありますね。
> そう、Kuroさんの可処分時間をめちゃくちゃ食ってしまったろうと思うと感想を言うのがはばかられました…が、前述の通り慣れの問題なのでしょうというところで、お聞き流しください。失礼しました🙇♂️
なはは、ありがとうございます。
ロールバックでも構いませんが、できる限りの悪あがきはしてみようと思いまして、他のエディターの仕様をさらに調べてみました。
以下、言葉の定義としまして、行番号クリックからの行選択で、選択範囲のファイルの末尾に近いほうにカーソルが来るタイプを「末尾側カーソル」、その逆を「先頭側カーソル」とします。
また、行番号クリックで行選択できないものは、トリプルクリックなどで行選択します。
さらに、選択範囲からの上下キーが、「選択範囲基準」なものと「カーソル位置基準」なものに分類します。
---
# 末尾側カーソル
## 上下キーは選択範囲基準
- VSCode
- Sublime Text
- E〇Editor さん
- Word (末尾側、行末カーソル)## 上下キーは選択範囲基準 + 列 (X 座標) のみカーソル位置基準
- ワードパッド (末尾側、行末カーソル)
- Windows 11 のメモ帳 (末尾側、行末カーソル)
- Atom
- Visual Studio 2022
- Mery Ver 3.6.2## 上下キーはカーソル位置基準
- Notepad++
- サク〇エディタさん
- UltraEdit
- Emacs (行トリプルクリック)
- MIFES 11 (行番号ダブルクリック)
- Eclipse (行トリプルクリック)## 上下キーは選択範囲の解除のみ
- Inkdrop
- Brackets (選択時はカーソルの概念なし)---
# 先頭側カーソル
## 上下キーは選択範囲基準
- IntelliJ IDEA (行番号トリプルクリック)## 上下キーはカーソル位置基準
- 秀〇エディタさん## 上下キーは選択範囲の解除のみ
- WZ Editor 10---
という結果でした。
さて、これらの結果を見てみると「末尾側カーソル」は圧倒的に多いので、これは採用しても問題なさそうです。
選択範囲からの上下キーは、小さな仕様の差を無視すると「選択範囲基準」が多いようですし、Microsoft 系のアプリはこの方式になっているようですね。
それから、前回、列の保持と干渉してバグが…と思っていましたが、列 (X 座標) のみカーソル位置を保持するタイプも意外と多かったです。
特に、Atom と Visual Studio 2022 は、Mery Ver 3.6.2 と同じで、マウスで選択した場合は列を保持せず、キーボードで選択したときは列を保持する仕様でした。
> おお、そうだったのですね。そう言われるとこの仕様が良い気がしてきました（単純）
VSCode に準拠の安心感はありますよね。
結論としては、
・末尾側カーソル
・上下キーは選択範囲基準を採用する方向で、「列のみカーソル位置を保持」は、私自身、最初にバグかなぁと思ったほどですから、仕様のわかりづらさという点ではナシでしょうかね。
ということで、VSCode 準拠の方向で修正しようかなと思っています。
| Kuro | 返信 -
おお、だいぶ本気で調べていただいてありがとうございます。
> # 末尾側カーソル
>
> ## 上下キーは選択範囲基準
> - VSCode
> - Sublime Text
> - E〇Editor さん
> - Word (末尾側、行末カーソル)ここの並びは、なかなかつよつよな顔ぶれですね。
選択解除されたあとのカーソル位置の仕様が選択行数に関わらず一貫したものですし、よさそうに見えます。> ## 上下キーはカーソル位置基準
> - Notepad++
> - サク〇エディタさん
> - UltraEdit
> - Emacs (行トリプルクリック)
> - MIFES 11 (行番号ダブルクリック)
> - Eclipse (行トリプルクリック)このあたりは古き良き時代の面々という感じで、これまた色が表れていて面白いですね。
> ## 上下キーは選択範囲の解除のみ
> - InkdropInkdropはエディタ部にはCode Mirrorというエディタライブラリを使っていたと思うので、その系統はみな同じ動きかもしれませんね。知っているところですと、Obsidianとか、Joplinとか。
> さて、これらの結果を見てみると「末尾側カーソル」は圧倒的に多いので、これは採用しても問題なさそうです。
ひとまずこちらについては余計な要望でなかったようで、安心しました。
> ということで、VSCode 準拠の方向で修正しようかなと思っています。
そうですね、コーディング体験に一家言あるSublime, VSCode準拠ともなれば、長いものに巻かれるのが好きな私としても大変好ましく感じますｗ
| yuko | 返信 -
> - Left: 範囲選択が解除され、先頭位置にカーソルが置かれる (現行Meryと一緒)
> - Right: 範囲選択が解除され、末尾位置にカーソルが置かれる (現行Meryと一緒)いつの間にか(v3.6.1?)選択範囲時に左右キーで押した方向の範囲先頭末尾で解除されるのように変わったんですね。
そこだけ、マクロ＋左右キーショートカットで変えてたので地味に、そして個人的に嬉しい変更ですｗ
ありがとうございます orz自分のマクロでは縦書きでの上下と左右の切り替えができないのですが、能力のなさと縦書かなさで無視したことを久々に思い出しましたｗ
| MM | 返信 -
Ver 3.6.1 からの仕様変更ですね。
> そこだけ、マクロ＋左右キーショートカットで変えてたので地味に、そして個人的に嬉しい変更ですｗ
みなさんの反応が気になっていましたが、そう言っていただけると嬉しいです。
> - Left: 範囲選択が解除され、先頭位置にカーソルが置かれる (現行Meryと一緒)
> - Right: 範囲選択が解除され、末尾位置にカーソルが置かれる (現行Meryと一緒)左右については問題ないのですが、上下はちょっと課題があります…
選択開始位置が 1 行目または最終行にある場合、上下キーで選択範囲が解除されないケースが発生します。
この問題は次のバージョンで修正予定ですので、リリースまで今しばらくお待ちくださいませ。
| Kuro | 返信 -
ブログの変更ログの
> 3.6.2 (2023-10-29)
> 1 行選択で、カーソルが次の行の行頭にある場合、[自動マーカー] の対象になるようにした1 行選択している行を削除して、そのまま [Shift] + [↓] で新たに 1 行選択しても自動マーカーが効きません（ハイライト表示されません）。
削除した行に繰り上がったテキストの行の行番号のクリックでも同様です。その行以外なら自動マーカーが効きます。
トリプルクリックは自動マーカーが効きます。| 774 | 返信 -
ご報告ありがとうございます。
いただいた条件のもとで現象を再現できました。次のバージョンではこの問題を修正できるよう、調査を進めますね。
ご不便をおかけしますが、今しばらくお待ちくださいませ。
| Kuro | 返信 -
Ver 3.6.4 で修正してみました。
ちょっと気になったのは、現在の仕様では、カーソルが動いたときだけ自動的にマーカーが更新されるようになっていますが、カーソルの動きがないまま選択範囲を解除する場合も考慮する余地があるようです。
たとえば、Ver 3.6.1 以降で導入された Esc キーによる選択範囲の解除や、選択状態で ← または → キーを押して選択範囲を解除する場合、または同じ位置でマウス クリックして選択範囲を解除する場合も、自動的にマーカーを解除したほうが良いかもしれませんね。
| Kuro | 返信 -
ご対応、ありがとうございます。
クリスマスプレゼントですね。＼^o^／今はパソコンがインターネットに接続できない状態ですので、確認は後日になりますが。
選択範囲の解除については、言われてみれば、選択範囲がなくなったのだから自動マーカーも解除されるのが自然なような気もしますが、選択範囲を解除することを目的に操作したことはないので、私としてはどちらでも構いません。
| 774 | 返信 -
メリークリスマス！＼(^o^)／
> 今はパソコンがインターネットに接続できない状態ですので、確認は後日になりますが。
今年の更新はこれで終わりなので、また、気が向いたときにでもご確認いただけるとうれしいです。
> 選択範囲の解除については、言われてみれば、選択範囲がなくなったのだから自動マーカーも解除されるのが自然なような気もしますが、選択範囲を解除することを目的に操作したことはないので、私としてはどちらでも構いません。
ご意見ありがとうございます。なるほど、参考になります。
私も今まであまり気にしていなかった部分で、放っておくのもいいのかなとも思ったのですが、気になり始めるとどうにも気になるので、次のバージョンではそのあたりも検討してみますね。
| Kuro | 返信 -
ご返信、ありがとうございます。
自動マーカーが効くようになったのを確認しました。> カーソルの動きがないまま選択範囲を解除する場合も考慮する余地があるようです。
認識済みかもしれませんが、文字列を削除したときもその１つですね。
今日たまたま遭遇したのですが、「あいあ」で「あ」を後ろから前へ向かって選択し削除したら残りの「あ」がハイライトされたままでした。
言われていなければ、そういうものだと思ったような気がします。| 774 | 返信 -
おめでとうございます。
旧年中はお世話になりました。
本年もよろしくお願いします。さっそくですが、自動マーカーについて新たなケースがありました。
例外ケースということで現状のままでも良いような気がしますが、一応報告します。
そろそろクレーマー扱いされそうで、報告すべきか迷いましたが。^^;下記ケースの行で、行番号をクリックして１行選択した場合に自動マーカーが効きません。
・行コピーしたものを貼り付けて、貼り付けた行の最下行
・行削除して、行削除した行の１行上の行
・行削除後にアンドゥして、アンドゥされた行の最下行
・複数行選択して、選択された行の最下行上２つは Ver.3.6.3 では OK です。
| 774 | 返信 -
ご報告ありがとうございます。
新年早々、いろいろな出来事が続いて心が重いですね。
こちらこそ、今年もどうぞよろしくお願いします。
> そろそろクレーマー扱いされそうで、報告すべきか迷いましたが。^^;
いえいえ、全然問題ありませんよ。
今回、ご報告いただいた自動マーカーが効かない問題も、Ver 3.6.4 リリース時に気になっていた「カーソルの動きがないまま選択範囲が変更されるケース」に関連するもののようです。
次のバージョンでは上記のケースに対応する予定なので、その修正により、問題は改善されると思います。安心してくださいね。
| Kuro | 返信 -
ご返信、ありがとうございます。
> 新年早々、いろいろな出来事が続いて心が重いですね。
そうですね。
地震は直後の映像では震度の割にそんなに被害がなさそうな感じでしたが、映されていない地域ではあれほどのことになっていたとは。> 今回、ご報告いただいた自動マーカーが効かない問題も、Ver 3.6.4 リリース時に気になっていた「カーソルの動きがないまま選択範囲が変更されるケース」に関連するもののようです。
言われてみればそれに該当しますね。失礼しました。> 次のバージョンでは上記のケースに対応する予定なので、その修正により、問題は改善されると思います。安心してくださいね。
よろしくお願いします。| 774 | 返信 -
リリース作業、お疲れさまでした。
前述のケースについて、自動マーカーが効くようになったのを確認しました。| 774 | 返信 -
> リリース作業、お疲れさまでした。
ご確認ありがとうございます。うまく動作しているようで安心しました。
Ver 3.6.5 は既知の不具合の修正がほぼ終わり、安定版としてリリースしたかったのですが、まだちょっと手つかずの部分が残っているんですよね。
その修正だけを行って安定版にするか、それとも修正と新機能を含めてベータ版を続けるか、まだ迷っています ^^;
| Kuro | 返信
