3

I've happily used count prefixes on search commands in vim for probably a couple of decades, so I know they used to count correctly. 5n was equivalent to n 5 times.

As of some recent version, 5n is sometimes equivalent to n 5 times, and sometimes equivalent to n 6 times.

I can no longer type 5n, see the cursor stay in the same place while the "search wrapped" message appears at the bottom of the screen, and know that there are 5 whatevers in the file. Which sounds really silly when I try to explain it, but it's apparently something I was doing subconsciously all the time, so the new version is driving me crazy.

What could be causing the search repeat count to behave inconsistently, and how can I fix it?

About my environment: The active options as reported by :set are

  autoindent          expandtab           ruler               ttymouse=xterm
  background=dark     fileformats=        shiftwidth=2        viminfo=
  backspace=1       nofsync               swapsync=           wrapmargin=3
  cpoptions=BceFs$t nojoinspaces        notextauto
noequalalways       noloadplugins         tildeop
noesckeys           nomore                ttyfast
  completeopt=preview
  formatoptions=tcroq2b
  path=.,/usr/include,,,/usr/include/x86_64-linux-gnu
  printoptions=paper:letter
  runtimepath=~/.vim,/var/lib/vim/addons,/usr/share/vim/vimfiles,/usr/share/vim/
vim80,/usr/share/vim/vimfiles/after,/var/lib/vim/addons/after,~/.vim/after
  suffixes=.bak,~,.swp,.o,.info,.aux,.log,.dvi,.bbl,.blg,.brf,.cb,.ind,.idx,.ilg
,.inx,.out,.toc

Some of those settings come from the Debian packaging. The rest are my preferences. I don't do scripting, plugins, or any other fancy stuff.

Improve this question
3
  • 2
    Can you give a concrete example of a pattern which shows this issue? n does have logic to repeat count+1 times (see :h n) but the circumstances in which it happens is somewhat rare groups.google.com/forum/#!topic/vim_dev/cOjJrIk3pZg . Note that this change was made in early 2015. – Mass Oct 26 '17 at 2:37
  • 1
    A couple of the cpoptions flags (e.g. 'c') can change search fairly dramatically in some cases. Is it possible those flags changed recently? (Suggestion from Mass seems more relevant but leave no stone unturned...) – B Layer Oct 26 '17 at 2:39
  • 1
    Actually not rare at all.. (demonstrated by guillem's answer) – Mass Oct 26 '17 at 10:42
2

It looks like in the current version of vim the n command is guaranteed to move the cursor, unless there is exactly one match on the file.

However, the search command / will behave as you are used to. Consider a file with these contents:

word
word

Let's imagine that the cursor is at the beginning of the file. Searching for "word" will place the cursor at the beginning of line 2. Pressing 2n the cursor will move to the first line, triggering the "search wrapped" message. Now the cursor is in the first line, and if you press 2/<CR>, it will stay on the first line, also triggering the "search wrapped" message.

Workaround

You can remap n to restore the desired behavior:

nmap n /<CR>
Improve this answer
1
  • It is even more apparent if you have 5 lines containing words and press 5n, it will jump 6 times. This seems like a bug, or at least an unintended consequence (although to be fair, it is indeed documented).. – Mass Oct 26 '17 at 10:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy