折り返しを無視した行頭／行末への移動
-
「キーボード」に追加されたコマンドの「行頭へ移動」「行末へ移動」ですが、折り返し表示をしている場合、折り返し位置で止まってしまうので、折り返しをまたいだ(折り返しを無視した)行頭／行末への移動もあると便利かなと思います。
自分はマクロで実現できてるので現状困ってはいませんが、感覚的にはこっちの方が便利なので他にもそういう人がいるかなと。
マクロだと
document.selection.StartOfLine(false, mePosLogical);
document.selection.EndOfLine(false, mePosLogical);---
似非Emacserなので同じくカーソル移動や編集系のマクロ作ってた。以前はAutoHotkeyでやってたけど、AH停止中のファイル編集で脳がバグるのでマクロでするようにした。今回のコマンド追加でだいぶスッキリしそう。CLIではvi派。GUI環境ではキーバインドだけEmacs。元Macユーザなのでこうなった。Macはテキスト入力できるところではEmacs風キーバインドが使える。Emacsでは^x^c(終了)以外の操作した事ないｗ
| 村人 | 返信 -
ご提案ありがとうございます。
論理行の行頭/行末へ移動のコマンドについては、私も Ver 3.6.1 の開発段階で検討しました。
しかしながら、Mery はもともと Home キー (行頭へ移動) と End キー (行末へ移動) が、1 回押すと表示行の行頭/行末に移動し、2 回押すと論理行の行頭/行末に移動するという仕様を採用しています。(VSCode や Sublime Text なども同じです)
そのため、[論理行の行頭/行末へ移動] のコマンドを新たに用意する必要性を感じませんでした。
さらに、[論理行の行頭/行末へ移動] コマンドを別途追加する場合、多くのコマンドが必要になり、設定が複雑になることが懸念されました。以下はその例です。
- [表示行の行頭へ移動]
- [論理行の行頭へ移動]
- [表示行の行頭またはテキストの開始位置へ移動]
- [論理行の行頭またはテキストの開始位置へ移動]
- [表示行の行末へ移動]
- [論理行の行末へ移動]
- [表示行の行頭まで選択]
- [論理行の行頭まで選択]
- [表示行の行頭またはテキストの開始位置まで選択]
- [論理行の行頭またはテキストの開始位置まで選択]
- [表示行の行末まで選択]
- [論理行の行末まで選択]
- [表示行の行頭まで列を選択]
- [論理行の行頭まで列を選択]
- [表示行の行頭またはテキストの開始位置まで列を選択]
- [論理行の行頭またはテキストの開始位置まで列を選択]
- [表示行の行末まで列を選択]
- [論理行の行末まで列を選択]このような理由から、[論理行の行頭/行末へ移動] を別コマンドとして提供しないことを選択しました。
もし、[論理行の行頭/行末へ移動] コマンドが別途必要とされるご要望が多ければ、再検討してみたいと思います。
---
> 似非Emacserなので同じくカーソル移動や編集系のマクロ作ってた。以前はAutoHotkeyでやってたけど、AH停止中のファイル編集で脳がバグるのでマクロでするようにした。今回のコマンド追加でだいぶスッキリしそう。
そう言っていただけると、開発の苦労が報われた気がします。
私もときどき vi は使用しますが、Emacs は学生時代に授業で触れた程度でなじみが薄いため、今回の Mery でどれだけ Emacs 風の操作を実現できるのか、正直なところ自覚がありません。
Emacs を本格的に使われているユーザーさんからのご意見を聞くことは非常に興味深いと思っていますが、同時に少し緊張もしていたりします。
| Kuro | 返信 -
折り返し表示している場合の表示行の(段落中の)行頭や行末って流動的なので、
そこが編集ポイントになる事ってあんまりないんですよね。論理行の行頭へ移動してインデントの調整したり、
行末に移動して続きを書いたりすることが多いです。折り返しの有無で行頭や行末への移動が1回だったり2回だったりするよりは、
必ず1回で済む方が直感的かなと思った次第で。なのでこのような提案をしましたが、了解です。
| 村人 | 返信 -
なるほど、そう言われてみるとそうかもしれないですね。
通常、メモ帳や Word では、Home キーを押すと表示行の行頭 (折り返し位置) にカーソルを移動させるのが一般的で、それが当然の仕様だと思っていました。
Ver 3.6.1 では、Home キーのデフォルトの動作が [行頭またはテキストの開始位置へ移動] に変更されましたが、この仕様はそのままで、[行頭へ移動] コマンドのほうを表示行の行頭ではなく、論理行の行頭へ移動する仕様に変更する、というのはどうでしょうか？
これだと、コマンドが過剰に増える問題は解消され、折り返し位置が編集ポイントになることが少ないというご意見にも対応できそうです。
もちろん、[表示行の行頭へ移動] がなくなることについて、一部のユーザーさんにとっては不便に感じるかもしれませんが、[行頭またはテキストの開始位置へ移動] コマンドでほぼ代用できるのではないかと思います。
どうしても表示行の行頭じゃないと嫌だというユーザーさんがいらっしゃったら困っちゃいますが…
ちなみに、Emacs の動作を確認してみると、行頭は論理行の行頭へ移動するようですね。表示行の行頭へ移動するコマンドが別途用意されているかどうかは確認できませんでした。
また、VSCode では、デフォルトで cursorHome というコマンドになっており、Mery の [行頭またはテキストの開始位置へ移動] と同じように、表示行の行頭 → インデント位置 → 論理行の行頭と移動します。
ただし、別途、cursorLineStart というコマンドも用意されており、これをキーに割り当てることで論理行の行頭へ 1 発で移動できるようです。表示行の行頭へ移動するためのコマンドは見当たりませんでした。
というわけで、[表示行の行頭へ移動] はそもそも必要ないんじゃないかという案を考えてみましたが、いかがでしょうか？
できれば皆さんのご意見も聞いてみたいですね。
| Kuro | 返信 -
広く意見を求めていそうだったのでちょっと横槍を携えてやって参りました。
> Ver 3.6.1 では、Home キーのデフォルトの動作が [行頭またはテキストの開始位置へ移動] に変更されましたが、この仕様はそのままで、[行頭へ移動] コマンドのほうを表示行の行頭ではなく、論理行の行頭へ移動する仕様に変更する、というのはどうでしょうか？
個人的には、混乱を生むのであまりよくない気がします。
- 「行頭まで列を選択」「行末まで列を選択」は矩形選択のコマンドなので現状の表示行扱いでの行頭・行末の方が扱いやすいので表示行のままの方がいい
- 仮に矩形選択系の「行頭・行末」だけを現状の表示行扱いのままとすると、それ以外の「行頭・行末」表現は論理行での扱いということになり、あっちは表示行で、こっちは論理行…というように仕様把握に混乱することになりそうそんなところで、ちょっと角度を変えたアイデアなのですが、以下のようなものはいかがでしょうか？
- ショートカット設定の「分類」に「移動・選択」カテゴリを新たに用意し、現状の移動、選択系のコマンドはすべて「移動・選択」に寄せる
- 表示行の行頭・行末移動系と論理行の行頭・行末移動系コマンドを網羅し、「移動・選択」カテゴリに詰め込むこれには以下のような利点があると考えています。
- 氾濫する移動、選択系ショートカットを一箇所にまとめられる
- 移動、選択系ショートカットをいじるのは操作設定にこだわり持った一部ユーザーだと思うので、そういった玄人ユーザー向けのカテゴリにできる。つまるところ、「移動・選択」カテゴリはコマンドの氾濫を苦に感じない人たちのコーナーになるので、複雑化しても大丈夫だと思う
- 移動、選択系ショートカットはメニューバー「編集」には存在しないショートカット専用コマンド達なので、「編集」カテゴリから分離することで、分類とメニューバーとの対称性を高められるところで少し話のそれた話題なんですが、ショートカット設定画面では「分類」の表記ですが、キーボードマップ画面では「カテゴリ」の表記となっており、表記ゆれなので揃えたいなと感じました…。個人的には「カテゴリ」の方が好みです。
| yuko | 返信 -
> - 移動、選択系ショートカットをいじるのは操作設定にこだわり持った一部ユーザーだと思うので、
こだわりというか、それに指が慣れてしまってるというか。
別トピックの内容ではありますが、今回追加されたコマンドで設定して使ってみて、アウトラインペインはともかく、検索や置換などのウインドウでもカーソル移動系やテキスト編集系の設定が利かないのは辛いです。
| 村人 | 返信 -
ご提案ありがとうございます。
なるほど、矩形選択ですか。確かに、ご指摘のとおり、この場合は表示行扱いのほうがわかりやすそうですね。
> - 仮に矩形選択系の「行頭・行末」だけを現状の表示行扱いのままとすると、それ以外の「行頭・行末」表現は論理行での扱いということになり、あっちは表示行で、こっちは論理行…というように仕様把握に混乱することになりそう
[行頭へ移動] は既に、1 回押しで表示行、2 回押しで論理行というふうに、状況によって動作が変わる仕様になっているので、矩形選択のときに動作が変わっても違和感は少ないような気もします。
でも、1 回押し、2 回押しの仕様を潰して、1 発で論理行頭に行けるようにしてしまうと、矩形選択のときだけ表示行頭という仕様は浮いちゃいそうですね。…難しいです。
気分転換に、他のエディターの仕様も調べてみました。
VSCode は矩形選択の概念がないため、列選択のときに [論理行の行頭/行末へ移動] でも問題ないようですね。
Emacs は矩形選択の場合、折り返された行が矩形選択の対象外となるため、矩形選択のときに [論理行の行頭/行末へ移動] でも違和感は少ないようです。
> - 表示行の行頭・行末移動系と論理行の行頭・行末移動系コマンドを網羅し、「移動・選択」カテゴリに詰め込む
これは良いアイデアですね。
現在、カテゴリとメニュー バーの項目は 1 対 1 で対応しているため、これを分離するのは少し手間がかかりそうですが、一度作ってしまえば今後のコマンドの追加にも対応できそうですし。
ただし、コマンドが増えすぎることの解消にはならないため、たとえ玄人ユーザーさんでも、先の回答で例として記載したような、大量のコマンドには閉口しそうではありますね。
とりあえず、案としましては、
(1) 現状維持。
(2) 行頭/行末を論理行にし、矩形選択のときだけ表示行とする。
(3) すべての移動系・選択系のコマンドを網羅し、新しいカテゴリを作成する。
ということになりますね。
さらに、もうひとつの案として、以下を考えてみました。
(4) カテゴリは増やさず、[論理行の行頭へ移動] コマンドを追加し、一部のバリエーションを省略する。
普通に [論理行の行頭へ移動] コマンドを追加しますが、使用頻度の低そうなバリエーションを省くという案です。
具体的には、矩形選択時には表示行のほうが良いとのことから、以下のコマンドを省きます。
- [論理行の行頭まで列を選択]
- [論理行の行頭またはテキストの開始位置まで列を選択]
- [論理行の行末まで列を選択]さらに、VSCode や Emacs には存在しない以下のコマンドも省きます。
- [論理行の行頭またはテキストの開始位置へ移動]
- [論理行の行頭またはテキストの開始位置まで選択]これにより、追加するコマンドを以下の 4 つに抑えることができます。
- [論理行の行頭へ移動]
- [論理行の行末へ移動]
- [論理行の行頭まで選択]
- [論理行の行末まで選択]この数だと、従来の [行頭へ移動] などのコマンドを「表示行の～」のように表記することなく、[論理行の行頭へ移動] 関連の 4 つのコマンドを追加しても、違和感が少ないかもしれません。
> ところで少し話のそれた話題なんですが、ショートカット設定画面では「分類」の表記ですが、キーボードマップ画面では「カテゴリ」の表記となっており、表記ゆれなので揃えたいなと感じました…。個人的には「カテゴリ」の方が好みです。
表記ゆれには気づいていませんでした。
Ver 3.6.1 の開発中に、Word のキーボード設定画面を参考にしている際、Microsoft の用語として [分類] と表記されていることに気づき、やだなぁ…と思いながらも変更しました。
私も [カテゴリ] 表記が個人的に好みなので、[カテゴリ] 表記に戻す方向で検討してみますね。
| Kuro | 返信 -
> 別トピックの内容ではありますが、今回追加されたコマンドで設定して使ってみて、アウトラインペインはともかく、検索や置換などのウインドウでもカーソル移動系やテキスト編集系の設定が利かないのは辛いです。
これは Ver 3.6.1 からの仕様というわけではなく、従来からの Mery の仕様ですね。
フォーカスが他のウィンドウにある場合、メイン ウィンドウのショートカット キーが効かないのは、Windows アプリケーション全般で一般的な仕様だと思われます。仕様上の制限事項ということでご了承ください。
| Kuro | 返信 -
> 普通に [論理行の行頭へ移動] コマンドを追加しますが、使用頻度の低そうなバリエーションを省くという案です。
それもいいですね！
そもそもMeryではマクロでいかようにもできるというのが前提にありますしね。利用頻度の低いであろうコマンドは標準で用意しない、という考え方はMeryらしい気はします。それはそれとして、移動・選択系の新カテゴリはやはり分けられているとコマンドを見つけるのが楽になるかなぁとは思いました。今回のバージョンでそれなりに移動・選択系のショートカットが増えていますし、2ストロークショートカットも搭載していただいたおかげでキー設定を色々試すことが増えることでしょうし。(とはいえ、ある程度設定が落ち着いてしまえばそうそう触ることはなくなるでしょうけど😅)
ところで、ショートカットキーの設定を触っていたところで気づいてしまったのですが、「新しいショートカットキー」のキーバインドを受け付けるボックス内で、入力キーが表示されている状態で Ctrl+A を押すと「Ctrl+A」と表示されるのではなく、入力されているキーが全選択されてしまいますね。
初回入力時 (入力キーがまだ表示されていない状態) だと、正しく「Ctrl+A」と表示されるようです。| yuko | 返信 -
あ、ちなみにですが、私自身は今回搭載された「行頭またはテキストの開始位置まで選択」の「折返し時の Home 2度押しで論理行頭」な仕様に満足しており (というか同じ動作をするマクロを以前から使っていた)、実のところ「論理行の行頭／行末に移動」系の動作をどこまで網羅するか、という点についてはまったく希望がなかったりします。 (それなのに横槍入れてすみませんなんですけど…😅)
| yuko | 返信 -
> それはそれとして、移動・選択系の新カテゴリはやはり分けられているとコマンドを見つけるのが楽になるかなぁとは思いました。
確かにそうですね。(3) と (4) をあわせて、コマンドの数を減らした上で、[移動/選択] カテゴリを追加するのが良さそうですね。
Ver 3.6.1 で追加された移動と選択のコマンドはすべて [移動/選択] カテゴリに移すことを考えていますが、[すべて選択] コマンドはメニュー バーにあるので、[編集] カテゴリに置いておくのが良いのかなぁ…😅
> 入力キーが表示されている状態で Ctrl+A を押すと「Ctrl+A」と表示されるのではなく、入力されているキーが全選択されてしまいますね。
うわ、ほんとですね。現象、確認しました。
どうやら、Windows の力が働いているようです。これは次のバージョンで修正しておきますね。
> 実のところ「論理行の行頭／行末に移動」系の動作をどこまで網羅するか、という点についてはまったく希望がなかったりします。 (それなのに横槍入れてすみませんなんですけど…😅)
いえいえ。貴重なご意見、ありがとうございました。とても参考になりました。
矩形選択のことは完全に忘れていました。あのまま仕様を変更していたら、恐らく他のユーザーさんからもツッコミが入ったことだと思います😱
ちなみに、私は、テキストの開始位置ではないほうの、従来のシンプルな [行頭へ移動] 派です。だから、Ver 3.6.1 で Home キーのデフォルトを変更するのは嫌で嫌で…。
| Kuro | 返信 -
> Ver 3.6.1 で追加された移動と選択のコマンドはすべて [移動/選択] カテゴリに移すことを考えていますが、[すべて選択] コマンドはメニュー バーにあるので、[編集] カテゴリに置いておくのが良いのかなぁ…😅
悩みどころですねー。コマンド名からしたら「移動/選択」カテゴリだけど、メニューと対となる「編集」カテゴリに置いておきたい…と。
私も、「基本はメニューバーと対になるカテゴリに配置」派で、「編集」カテゴリの方がしっくり来るかなぁと思いました。あるいは「移動/選択」カテゴリの成り立ちが特殊 (メニューバーに存在しないカテゴリ) なので、他のカテゴリとの重複を気にせずに「すべて選択」を「編集」カテゴリにも「移動/選択」カテゴリにも両方に置いてもいいかもしれません。
とはいえ複数カテゴリに存在することで実装がかなり複雑になるなら、そこまで力を入れなくてもいいところだと思いますが。> ちなみに、私は、テキストの開始位置ではないほうの、従来のシンプルな [行頭へ移動] 派です。だから、Ver 3.6.1 で Home キーのデフォルトを変更するのは嫌で嫌で…。
oh.. そうだったのですね。
プログラミングを嗜む方は論理行扱いが好みの方が多いのかな、なんて勝手に思っていましたが、やっぱり色々ですね。| yuko | 返信 -
> とはいえ複数カテゴリに存在することで実装がかなり複雑になるなら、そこまで力を入れなくてもいいところだと思いますが。
両方に表示する場合、コマンド一覧に対してカテゴリでのフィルタリングのような、データベース的な仕組みが必要になるかもしれません。
将来的に、コマンドの名称での検索などを実装する予定があれば、そのような仕組みが必要になりそうですが、[すべて選択] のためだけには、ちょっと気が滅入りますね。
> 私も、「基本はメニューバーと対になるカテゴリに配置」派で、「編集」カテゴリの方がしっくり来るかなぁと思いました。
ですよねー！その方向で開発を進めてみます。
> プログラミングを嗜む方は論理行扱いが好みの方が多いのかな、なんて勝手に思っていましたが、やっぱり色々ですね。
私は秀丸エディタで育ったものですから😁 そういえば、Delphi の IDE もシンプルな行頭へ移動でした。
ひとまず、方向性が決まったので良かったです。いただいたご意見を参考に、もう一度、整理しつつ検討させていただきます。
| Kuro | 返信
