henrik / vim-indexed-search

Show "Match 123 of 456 /search term/" in Vim searches. By Yakov Lerner.

IndexedSearch.vim

Requires vim7.4

Originally by Yakov Lerner and put on GitHub by Henrik Nyh to have it there in a Pathogen-friendly format. Majorly rewritten by Otto Modinos.

See the original plugin page at vim.org.

This plugin redefines 6 search commands (/,?,n,N,*,#). At every 
search command, it automatically prints>
       "At match #N out of M matches". 
>
-- the total number of matches (M) and the number(index) of current 
match (N). This helps to get oriented when searching forward and 
backward. 

There are no new commands and no new behavior to learn. 
Just watch the bottom line when you do /,?,n,N,*,#. 

See full help file.

Alternatives

Is this plugin too slow for you? Do you want more (or less) features? Here're some other plugins that do (or can do) the same thing:

• On Vim 8.1.1270+, you can use :set shortmess-=S
• google/vim-searchindex; very fast and unobtrusive
• osyo-manga/vim-anzu; tons of features
• romainl/vim-cool; initally just for disabling the highlighting of matches after a seach, now also show an index
• lacygoill/vim-search; meant for personal use but can be used by everyone

vim-indexed-search's Issues

Respect existing mappings

Currently I have nmap n nzz and nmap N Nzz in my vimrc to center the screen on the matches when cycling through them. I tried changing the nnoremaps in vim-indexed-search with nmaps thinking that would allow me to have both, but for some reason that didn't work.

Any idea how what else I would need to change or could you add an option to allow remaps/centering?

Breaks visual star search

This could be related to #21 but I'm also using another plugin, nelstrom/vim-visual-star-search and it seems like vim-indexed-search is causing an issue.

If I visually select some text, say something inside quotes like 'henrik/vim-indexed-search', without this plugin the whole bit inside the quotes, that whole string stays highlighted and vim shows me other instances of that same full string. But with this plugin installed, the highlighted selection pops over to the last word in the string. so in the case above, it'd only highlight the search bit of the 'henrik/vim-indexed-search' string. Any thoughts? Thanks!

breaks / selection

When I run command like vc/ (select to the next space), or some other command which takes search result as an object, that selections just blinks for a second and collapses again, so in the end nothing is selected. I guess some unruly times is at fault, but when I uninstalled this plugin (because this functionality is very important for me), everything works fine again.

Using neovim from HEAD on RHEL-7 (neovim/neovim@8d5a46e77 ATM).

LICENSE missing?

Hello.

I've borrowed code from this plugin in order to incorporate index funcitonality in vim-slasher.

I've included proper credits in the README of the document. The problem is that I just realized this plugin doesn't have any license file, so I'm not sure if I'm actually allowed to do that.

Would you be kind to provide a LICENSE profile just to be sure? Or that depends on the original developers of this plugin?

W19: Deleting augroup that is still in use

Using the latest versions of Vim I get this error (W19) instead of the search index.

:h W19 says not to use augroup! "if there is still an autocommand using this group", so I suppose that's what's happening here. I looked into your s:destroy_augroup() function and changed the line that says

execute "augroup! ". a:group

to

execute "silent augroup! ". a:group

And it makes the plugin usable again, but I think this should be fixed properly, instead of just hiding the error message.

---

Edit: It seems that changing the CursorHold autocmd to this fixes this problem without changing anything in the functionality:

autocmd CursorHold *
    \ let &ut = s:save_ut            |
    \ call s:echo_index(s:force)     |
    \ autocmd! IndexedSearchAutoCmds |
    \ augroup! IndexedSearchAutoCmds

It seems like the autocmd! line at the s:destroy_augroup() function isn't doing its job for some reason.
I can make a PR if you want me to, I just didn't already because I'm not 100% sure this is the way to go.

Did some testing, turns out we're slooow

Recently, I found some other plugins that do the something as we are: providing an index into your searches. I thought I'd take the time to check how they do things compared to us. In particular, there is vim-searchindex that uses a complex caching algorithm and I thought "is this all necessary, I've never felt vim-indexed-search to be slow". Turns out, I was just not searching (get it?? :D) enough.

The competiton

So, without farther ado, let's see what we're up against. I will be comparing two things: correctness, whether or not the results are correct in every case, and speed.

• henrik/vim-indexed-search; that's us.

  • Correctness. Our algorithm is actually not always correct. In particular, star commands (*, #, g*, ...) do not respect the smartcase options while the search() vim function that we use does. Try it out, run set ignorecase smartcase, write foo Foo in a buffer and "star" the second Foo. While both of them are matches for vim we only report the one.

  • Speed. We're actually slow, hence the name of the issue. This was quite a surprise, given how simple the algorithm is, but as can be seen bellow, we're the slowest of the bunch.

• google/vim-searchindex

  • Correctness. They provide a custom mapping for *, #, g* and g# and even an option to make these commands respect case.
  • Speed. They're really fast. Like, for real.

• romainl/vim-cool; added a search index capability recently using a very unique approach.

  • Correctness. They manage to stay correct without any custom mappings by utilizing the same mechanism that the user is; the 'n' and 'N' commands. This does mean that there are a number of edge cases to take into account but nothing unsolvable.
  • Speed. The base algorithm as implemented in the plugin is very slow. However, there are ways to get better performance.

Benchmarks

Now, let's get a-measuring. I created a 15kB file of random base64ed data, searched for . and used the profile functionality of vim to measure performance. I run each algorithm 10 times at the very top of the file, 10 times in the middle and 10 times near the end. Each time the cursor also moves a little so that the caching algorithms don't get away with doing literally nothing; they'll just do very little.

FUNCTIONS SORTED ON TOTAL TIME
count  total (s)   self (s)  function
   30  17.046901             <SNR>111_cool()
   30  13.101501             <SNR>111_current()
   30   8.098149             Cool_gallop()
   30   2.196443   2.192264  <SNR>111_vimgrep()
   30   0.337265   0.005592  Cool_cache_gallop()
   30   0.233058   0.227023  <SNR>111_substitute()
   30   0.025718   0.006094  <SNR>111_searchindex()

• s:cool() is the algorithm taken straight from the plugin
• s:current() is our current algorithm
• Cool_gallop() is an algorithm based on the "cool" idea (using just n, N) but it first searches using 10n, the n command with a count of 10. This is the same as doing n 10 times but since the loop is done internally it ends up being faster.
• s:vimgrep() uses, you guessed it, the vimgrep command. While that is fast on its own, getting the results back is veery slooow (comparatively) since it passes a list with all the matches. There's also the problem of correctness; vimgrep never uses smartcase so star searching will be correct, all the other ones won't be though.
• Cool_cache_gallop() tries to combine Cool_gallop() with the caching of vim-searchindex but it's still quite buggy.
• s:substitute() just uses substitute with the n flag that reports the number of matches. It is very simple and fast but not at all correct; substitute works only linewise.
• s:searchindex() is the algorithm straight from the plugin. At its core it uses substitute to count the matches in the lines above and then uses search() in the current line. That on its own is fairly fast, however the secret sauce is its caching. Using that, they only ever have to count the matches in the lines since the previous counting.

Conclusions

Where do we go from here?

Add case sensitive support

Can you add another mapping for search case sensitive when press * or #

Breaks backward search with S-# + n

Please remove the feature introduced by this commit:

96703af

I don't understand how it is relevant to the purpose of this plugin - seems like it should be in a plugin of its own. Plus, it breaks the default vim behavior and is poorly documented. If anything, I think the default value should be "0" and let those who're interested in this quirk switch it to "1".

The option to keep the cursor on the current match no longer works

Seems like the functionality I added in a PR a while back to not jump to the next match on initial search is broken / removed.

Frequently I want to just visually see all instances of a given word highlighted on the screen when typing on a given line, so having the cursor jump away from where I am is quite jarring. Can we add that functionality back please? Thanks!

this plugin conflicts with vim built-in search behavior

type / in vim normal mode and search a string, with vim's genuine ability, you can go to the n-th search by pressing 'n' or 'N' after a given number.

while with this plugin turned on, the genuine key binding does not work, giving warning: E481: No range allowed.

can this be improved to make it compatitable?

Key maps doesn't work in latest commits in Neovim

My config: https://github.com/unclechu/neovimrc
You could look at this commit that freezes commit before update which is working:
unclechu/neovimrc@52b5029#diff-23d016fb30028357a122b2cb3d106ee2R23
This one: 5f36c32

When I press any key mapped to <Plug>(indexed-search-... nothing just happens.
You could find my own these maps here: https://github.com/unclechu/neovimrc/blob/master/maps.vim
It doesn't works in even latest Neovim (NVIM v0.2.3-934-g98e7112 dated by 31 March 2018). I don't have any info if it's working in Vim or not.

I realized it isn't working first time with this commit: cfc43d5