TODO リストで取り消し線を引いています。最近コレマックを手に入れました。次に、Vim か Emacs を学びたいと思いました。私は Vim に傾倒していましたが、Vim の利点の 1 つはホーム ラインに固執することです。コレマックでホームローが変わった。キーを再マッピングできることはわかっていますが、機能を別の文字に割り当てることはあまり魅力的ではありません (文字とその機能の間に何らかの関係がある場合)。動きが相関していないことは知っていますが、残りのすべてについてはわかりません.)
テキスト エディターについての論争的な投稿を開始したくはありませんが、代わりのキーマッピングとこれら 2 つのエディターについて Colemak (または Dvorak) ユーザーからのコメントを受け取ります。
ありがとう
私はGrahamと同様の設定を使用しています(上、下、左、右は hkjl (Qwerty hnyu) です) が、noremap を使用する代わりに、.vimrc で langmap を使用して再マップします:
set langmap=hk,jh,kj
これには、これらの移動キー (g、z、Cw など) を使用する他のコマンドを、手動ですべてのコマンドを再定義することなく変更できるという利点があります。
私は最近 Colemak に切り替え、Vim をメインのエディターとして使用しています。
移動キーやその他の Vim キーを再マップする必要はないと言えます。あなたの脳は、移動キーの新しい位置をすぐに学習します。ニーモニック キーの場合、再マップする必要はまったくありません。ニーモニックの意味をキーの背後に保持する必要があります。
Vim の移動キーを再マップすると、たとえばサーバーに SSH 接続する必要がある場合など、バニラの Vim を実際の効率で操作できないという不幸な状況に陥ります。私は、ほとんどの人にとって、Colemak を持っていない誰かのコンピュータを使用しなければならないよりもはるかに一般的であると主張します.
同様に、ある日入手した Vim プラグインが再マッピングと衝突する可能性があります。または、ある日、再マッピングしたために現在使用できない機能に関する Vim のヒントを読むことがあります。
それはあなたにとって本当に苦痛になるので、私は再マッピングを気にしません.
別の Colemak ユーザーに会えてうれしいです :)
Emacs の場合、最初の「ショートカット」は互いに接近するように設計されていないため、実際に再マップする必要はありません。どちらかといえば、Qwerty よりも Colemak で Emacs を使用する方が快適になるでしょう (少なくとも私はそうでした)。
Vim では、hjkl が完全にめちゃくちゃになるので、かなりトリッキーです。繰り返しになりますが、hlkl は壊れていて、代わりに jkj であるべきだといつも感じていました。または ijkl であるため、リマップはおそらく良いことです。Colemak フォーラムでの Colemak+Vim に関する広範な議論は次のとおりです: http://forum.colemak.com/viewtopic.php?id=50
h/j/k 文字にのみ影響するため、.vimrc 内のこれにより、他の vim マッピングに影響を与えることなく Colemak のカーソルの動きが変更されます。
マッピングは次のとおりです。
noremap h k
noremap j h
noremap k j
私は Dvorak を何年も (おそらく ~4 年) 使用してきました。また、vim のようなものを使用する必要があるすべての標準的な理由で vim を使用しました (以下、独自のエディター (visudo など) を持つ構成編集など)。Emacs は実際に私が最初に学んだ Unix プログラムであり (私は Apple の世界の出身です)、Yegge のとりとめのないことでそれがどれほどばかげているかについて非難された後、私は現在それを取り戻しています。
厳密なキーボード レイアウトのスタンスからすると、再マッピングが必要ないため、おそらく Emacs が勝者であると言えます。Caps-Lock キーを Control キーに交換する以外は (Caps-Lock キーは、すべてのキーボードの高校のヒッキーのようなものです)、すべてのキーバインドは、Dvorak を使用するよりも Dvorak を使用する方が快適であると言えます。四分の一。特に、常に使用される Cx および Mx バインディングは、入力するのが非常に快適であることがわかりました。
ただし、vim は大したことではありません。「j」と「k」はまだ隣同士です。'h' と 'l' は、少なくとも一方では便利で、ホーム ロウの上にあります。それ以外は、エディターで実行したいことを実行するために、頭の中でキーを再マッピングするだけです。個人的には、何かをリマップする理由が見当たらず、RSI のリスクが高い (したがって、Dvorak に切り替える)。vim や emacs のようなキーボード中心のアプリの場合、それらを変更せずに快適に使用できるという事実はかなり印象的です。:)
幸運を！
私はVimにRyan Heiseのソリューションを使用しています:
上下のナビゲーション キーの物理的な位置を保持する "NEST" ナビゲーション バインディングを思いつきました (左右は異なりますが、ホーム行にあります)。
N = 下 E = 上 S = 左 T = 右
これを設定するためのコマンドは、私の Colemak ページの下部にあります。
http://www.ryanheise.com/colemak/
ほとんどの場合、これらのバインドにより、通常の vim チート シートを使用してコマンドを学習できますが、もちろんナビゲーションは除きます。
NEST で割り当てられた 4 つのキーのうち、"N" ("n" 次の検索結果) と "E" (現在の単語の "e" 番目に移動) は頻繁に使用されましたが、飲み込まれました。これらを元の QWERTY 位置に再マップしたため、元の論理名を持たないコマンドは 2 つだけです。
https://forum.colemak.com/topic/50-colemak-vim/p2/#p2514から取得
私は vim+qwerty ユーザーです (dvorak を学習してみましたが、タイピング速度はレート制限要因ではなく、RSI の問題はありません)。vi(m) の hjkl カーソル移動キーのみが位置に依存し、その他はすべてニーモニックです。Colemak のレイアウトを見ると、h/l は漠然と左/右ですが、j/k は下/上です。とはいえ、それが重大な障害になるとは思えません。代わりに矢印キーを使用するか、引き続き hjkl を使用しておかしな位置に対処することができます。
キーボード レイアウトに応じて vim 関数を再マップしようとする気はありません。それは私にとってあまりにも多くの潜在的な混乱のようです.
これはあなたに役立つはずの以前の投稿です。そこにはいくつかの議論があり、一部のユーザーは再マップしません。いくつかはそうします。
私は実際に週末にリマップするつもりです。私は過去 1 年間、Dvorak でデフォルトのマッピングを使用してきました。