分かりやすいKey-mappingsの弊害

上記の記事で紹介されている「分かりやすいKey-mappings」だけど、実はちょっとした罠が潜んでいる。

問題

例えば prefix に <Space> を使ったとしよう。

nnoremap <Space> [Space]
nmap [Space] <Nop>
" ...

ここで、とあるプラグインが専用のバッファを作って <Space> に対してバッファローカルなマッピングを生成したとする。

nmap <buffer> <Space> <Plug>(plugin-some-func)

この場合、<Space> に対して設定されているキーマッピングは以下の 2 つだけになる。

n  <Space>     * [Space]
n  <Space>      @<Plug>(plugin-some-func)

グローバルなキーマッピングバッファローカルなキーマッピングが両方ある場合、バッファローカルなキーマッピングが優先されるので、<Space> を押しても常に <Plug>(plugin-some-func) に展開されるため、このバッファでは <Space> を prefix にしたキーマッピングは一切使えなくなる。これはひどい

使わなかったら使わなかったで別の問題が

じゃあカッコつけて変な設定しないで、素直に設定すればいいのかと言うと、「分かりやすいKey-mappings」ほどではないにしても問題は残る。
例えば素直に設定した場合、

nnoremap <Space> <Nop>
nnoremap <Space>w :<C-u>update<CR>
nnoremap <Space>q :<C-u>quit<CR>
" ...

こんな感じで、先ほどのバッファローカルなキーマッピングがある場合は、<Space> まで入力した時点で Vimマッピング先を決定するために待ち状態になる。次に w や q など存在するキーが入力された場合はそのマッピングに展開され、存在しないキーを押したり、設定にもよるが 'timeoutlen' で設定した時間経過した場合は <Plug>(plugin-some-func) に展開する。
つまり、<Space> を押してもバッファローカルな機能がすぐには発動しない。これはこれで困る。

ではどうしろと

実際のところ、「プレフィックスキーに使ってるキーには何もマッピングするな」くらいしか解決策はない。
プラグインが勝手に設定する場合は、カスタマイズ方法が提供されている場合はそれに従って設定し、提供されてない場合は、そのプラグインを窓から投げ捨てるか、中身を勝手に書き換えるかする。
で、逆に言えばきちんと対処すれば「分かりやすいKey-mappings」を使ってもまったく問題はない。
要するにこの話は、この対処をしなかった場合にどちらの方が被害が大きいかと言うと「分かりやすいKey-mappings」を使った場合の方が問題になると思うよ、ってこと。