Windows 版での navigate-forward / navigate-back のキー割り当てが OS 標準ショートカットに重複している

v5 リリースお疲れさまです!

以下ご報告いたします。

バグ報告

v5 で新しく実装された navigate-forward/navigate-back 機能は、 Windows 版だと ctrl-left/ctrl-right に割当たっています。
これは、OS 標準動作の単語移動のショートカットと衝突するため、navigate-forward/navigate-back は発動しません。

Windows ではブラウザや Explorer で alt-left/alt-right に同様の戻る/進むが割当たっているため、こちらのキーが適当かと考えています。

ただし現状のデフォルトでは、alt-left/alt-right には editor:go-line-start/editor:go-line-end が割り当てられており、今度はこちらと衝突します。

個人的には、この動作は Windows においては Home/End キーを使用するのが一般的だと思いますので、 navigate-forward/navigate-back として割り当ててもいいかと考えています。

利用環境

  • Platform: Windows
  • Platform version: 10
  • App Version: 5.0.0

Yukoさん

お久しぶりです!
なるほど、Windowsでは alt-left / alt-right がデファクトなんですね。変更したほうが良さそうですね。

エディタにフォーカスがある時にこのショートカットキーが動作しないのは、仕様です。
例えばノートリストにフォーカスがある時は動作するはずです。
この仕様の理由は、エディタにはご指摘に通りすでに沢山のショートカットキーがあり、各自カスタマイズもされていると思われるためです。

HomeEndはノートリストのスクロールと衝突する気がします。
このあたりは好みと思われます。

ご意見ありがとうございます!

エディタにフォーカスがある時にこのショートカットキーが動作しないのは、仕様です。
例えばノートリストにフォーカスがある時は動作するはずです。

確かに動作しますね。すみません、確認不足でした…:sweat_smile:

それと、語弊があったので訂正を。

個人的には、この動作は Windows においては Home/End キーを使用するのが一般的だと思いますので、 navigate-forward/navigate-back として割り当ててもいいかと考えています。

editor:go-line-start/editor:go-line-end (行先頭/末尾移動) は Home/End キーで操作するのが Windows では OS 標準動作として一般的なので、エディタ上にフォーカスがある場合でも navigate-forward/navigate-back として alt-left/alt-right を割り当ててしまってもいいと思う、というお話でした。

とはいえ、

エディタにフォーカスがある時にこのショートカットキーが動作しないのは、仕様です。
この仕様の理由は、エディタにはご指摘に通りすでに沢山のショートカットキーがあり、各自カスタマイズもされていると思われるためです。

とのことで、エディタにフォーカスしている時はそもそも navigate-forward/navigate-back を発動させない設計思想とのこと、了解しました!

エディタにフォーカスしている時はそもそも navigate-forward/navigate-back を発動させない設計思想とのこと、了解しました!

私は発動する選択肢がほしかったです。

紹介動画でも「ノートを書いている最中、他のノートを参照することが多々あるかもしれません」「素早く編集していたノートに戻れる機能は重要です」と言われています。全く共感しますし、この機能を実装して頂いたのは感謝します。

できれば、ナビゲーションで移動するときは、カーソル位置またはスクロール位置を覚えていてくれると、最高に機能します。

私は発動する選択肢がほしかったです。

選択肢としては用意されているようです。
keymap.cson でキーバインド設定をすれば、エディターにフォーカスがある場合でも発動させられます。

Windows の場合

'.CodeMirror textarea':
  'alt-left': 'core:navigate-back'
  'alt-right': 'core:navigate-forward'

実際私もエディターにフォーカスしている状態で使えた方が便利だと考えているので、これを設定して使っています。

できれば、ナビゲーションで移動するときは、カーソル位置またはスクロール位置を覚えていてくれると、最高に機能します。

欲を言えば、 VSCode や IntelliJ 等のエディター・IDEのような Ctrl-Tab の動作 (直前に開いていたタブに遷移) もできると嬉しいです…:slightly_smiling_face:

1 Like

Yukoさんの使いこなしが凄いw さすがベテランユーザですね。

僕はマウスの第4&5ボタンで行き来しているので、不満は無いんですよね。

確かにそうですね。参照して戻ってくる際により素早く再開できますね。検討してみます。

この挙動はちょっとよく分かりませんでした。

この挙動はちょっとよく分かりませんでした。

すみません、ちょっと分かりづらいですよね。

まず例として VSCode でのデフォルトの Ctrl-Tab の動作のサンプルを掲載します。

20200902-135432

上記サンプルではファイル A, B, C, D があります。
最初の状態では、以下の順序及び履歴で開いています。

  1. A: 2つ前に開いていたファイル
  2. B: 現在のアクティブファイル
  3. C: 3つ前に開いていたファイル
  4. D: 1つ前 (直前) に開いていたファイル

Ctrl-Tab を押すと、直前に開いていた D が開かれます。
これにより履歴状態は以下のように変わります。

  1. A: 2つ前に開いていたファイル
  2. B: 1つ前 (直前) に開いていたファイル
  3. C: 3つ前に開いていたファイル
  4. D: 現在のアクティブファイル

Ctrl-Tab を再度押すことで、直前に開いていた B が開かれます。
これにより履歴状態は、以下のように変わります。

  1. A: 2つ前に開いていたファイル
  2. B: 現在のアクティブファイル
  3. C: 3つ前に開いていたファイル
  4. D: 1つ前 (直前) に開いていたファイル

この状態で Ctrl-Tab → Tab を押します。(Ctrl を押したまま、Tab を2回押す)
すると、2つ前に開いていた A がアクティブになり、履歴状態は以下のように変わります。

  1. A: 現在のアクティブファイル
  2. B: 1つ前 (直前) に開いていたファイル
  3. C: 3つ前に開いていたファイル
  4. D: 2つ前に開いていたファイル

これらのファイルをタブの表示順に遷移するには、Ctrl-PageDown/PageUp を使います。(Mac ではどのキー割当たっているか分かりませんが…)

この動作が嬉しいのは、関連する複数のファイルを行ったり来たりしながら記述していくケースです。
Ctrl-Tab だけで現在のファイルと直前のファイルを行き来できるので、2つのファイル間を相互に確認しつつ記述する際に便利です。 (Windows の Alt-Tab, Mac の Command-Tab の履歴遷移に似ています)

この直前のファイルへの遷移動作を、Inkdrop 内のノート遷移に見立てたイメージをしていました。

ただ軽い気持ちで要望してしまったものの、修飾キーを離したときに初めて履歴状態が更新されるなど、実装難度も高そうですね… :sweat:

1 Like

なるほど、エディタ部分ではできないようになっているものと早とちりしてしまいました。
便利なので、早速設定します!

確かにctrl+tabができると嬉しいですね。
別ウィンドウに開いて、普通にalt+tab、cmd+tabすればいいという考え方もあるとは思いますが、同じウィンドウで片付けたい感もあります。

ただ、タブは開いているファイルなので有限ですが、履歴は多数になると思うので、そのあたりの整合性もあるかもしれません。

ぶっ飛んだ話になりますが、一時的なタグのようなものがあればいいのかも。
ctrl+tabがあるといいなというシチュエーションを思い出し

  • _workspaceというタグを作る
  • 作業に使うノートにタグ付けする
  • タグからノート一覧を開く

といったことをやってみて、ctrl+tabがノートリストの下で止まらず、上に戻ってループしてくれたら、近しい使用感が得られる感じがしました。課題は

  • 更新されてからリストの順番が変わるまでのタイムラグが大きい
  • 終わる都度タグを消す面倒くささ

workspace featureとしてピン留めとか色々実装して頂いて、とても便利になりましたが、その延長のような考え方かもしれません。

妄想なので無視して頂いて結構ですが

  • ノートを右クリックして「bookmark on workspace」を押す
  • All NotesとNotebooksの間に「Workspace」が登場する。
  • 仕様はタグを開いたときと同じ。
    ただしctrl+tabでのリスト移動は、ループ(一番下の次は一番上)
  • Inkdropを終了するとworkspaceは消える。
    残しておきたければタグを使えばよいけど、救済策として、ノートリストから直接タグ付けできると(複数一括設定対応)、普段使いでも便利だなと。

あぁ、絶対実装されない(笑)
プラグインで開発できるといいんでしょうね。スキル不足が痛い。
終了時に自動的に指定したタグを削除するプラグインができれば実現できるか。。。

1 Like

Yukoさん

詳しいご解説ありがとうございます!
なるほど、タスクスイッチのような挙動ですね。
確かにあると良さそうですが、Masayukiさんのご指摘通りヒストリーとはコンセプトが異なりますね。
Masayukiさんのアイデアもありがとうございます。
自分の中で強い必要性を感じたら前向きに検討したいと思いますが、今の所は個人の好みの範疇を超えず、プラグインで実装していただくのが最良に見えます。
自分が使わない機能はバグにも気づかず、動かない機能は結局ついていても意味がないというのが大きな理由です。経験則です。
もしお時間があればプラグインでの実装を検討してみてください!

1 Like

確かにあると良さそうですが、Masayukiさんのご指摘通りヒストリーとはコンセプトが異なりますね。

そうですね。
履歴を辿る動作に近しいものを感じましたが、よくよく詳細を書き出していくと、かなり異なる仕組みだなと気付きました、、、

ひとまず「時間があるときに作ってみたいプラグイン」のアイデアとして、したためておきたいと思います :relieved:

v5.0.1にて WindowsとLinuxにおける core:navigate-back / core:navigate-forward コマンドのキー割当てを alt-left/alt-right に変更しました!

1 Like

ありがとうございます!
動作、確認できました :ok_hand:

1 Like

できれば、ナビゲーションで移動するときは、カーソル位置またはスクロール位置を覚えていてくれると、最高に機能します。

こちら v5.8.0-beta.1 にて対応しました! @Masayuki_Tahara