I use the enter key as my leader:

nnoremap <cr> <nop> " To avoid moving the cursor
let mapleader="\<enter>"

So far so good. To have the same behavior on Dirvish I need to remap enter to <nop> again, otherwise when I press it, it navigates to the path under the cursor (which I don't need because gf is already burned in my brain):

augroup DirvishSetUp
    autocmd FileType dirvish
        \ nnoremap <buffer> <cr> <nop> |
        \ nnoremap <buffer> <silent> gf :call dirvish#open('edit', 0)<cr>
augroup END

It works as expected, except for an annoying little detail: If I searched something previously, on any buffer, and press the enter key on the Dirvish one and wait, the last search gets repeated. :nmap shows the following for <cr>:

n <CR> *@<nop><Space>
n <CR> * <Nop>

Why is this happening? (Not sure if relevant, but this is on Neovim 0.4.3)

  • 2
    I'm too lazy to investigate properly, but does removing the space from the end of this line fix the issue? \ nnoremap <buffer> <cr> <nop>| Does doing so change the output of nmap <cr>?
    – Rich
    May 6, 2020 at 14:35
  • 2
    Yes, the issue is the trailing space which removes the special meaning of <nop>. Remove it; otherwise <nop> is no longer handled like a no-op, but as a sequence of literal keys (<, n, o, p, >).
    – user938271
    May 6, 2020 at 14:40
  • 1
    Yeah, that was the issue 😰 Is it documented somewhere? :h <Nop> says nothing
    – Tae
    May 6, 2020 at 14:42

1 Answer 1


The problem, as user938271 explains, is that by inadvertently including a space in the {rhs} of your mapping, you prevent <nop> from acting like a no-op, and instead it becomes a literal string of keystrokes: <, n, o, p, >.

In the resulting mapping, The < does nothing, and the following n repeats the last search.

This behaviour can be inferred from the documentation for <Nop>:

An easier way to get a mapping that doesn't produce anything, is to use "<Nop>" for the {rhs}.

Note that it doesn't say "in the {rhs}", but instead "for the {rhs}". This implies that if the {rhs} is not exactly <Nop>, but instead includes <Nop>, the special behaviour will not be triggered. (This wording could probably be improved, and I'm sure Bram would welcome a pull request for this.)

The space is included in the mapping is the one between the <nop> and the bar: |. Vim includes this in the mapping because it has no way of knowing this isn't what you intend. Thus, to fix the issue, change that line to:

\ nnoremap <buffer> <cr> <nop>|

Note that there are three clues that this is what was happening in the output of :nmap <CR>:

  1. In the first, buffer-local, mapping, <Space> is included,
  2. In that mapping the output has a lower-cased <nop> (what you typed) instead of the upper-cased <Nop> (Vim's notation for the special feature).
  3. This is not visible in the paste, but it is inside Vim: the <nop> in the first mapping is highlighted differently from the <Nop> in the second one. The latter is has special highlighting to indicate it is not a series of keystrokes, but instead a single <Nop>.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.