GNU id-utils provides a mkid command which scans a directory of files to build a binary index file called ID. The lid tool is used to query this and provides a grep-compatible mode.
lid sometimes puts out things in a funny order, so I sort the output.
:set grepprg=lid\ --word\ --result=grep\ '$*'\ \\\|\ sort\ -n\ -t\ :\ -k\ 2
Or, if you'd like :grep to use git grep:
:set grepprg=git\ grep\ -n\ '$*'In a large-ish project like the Linux kernel tree, there is no perceptible delay.
I use ctags in parallel with mkid; different tools for different job.
Speaking of :grep, I have it mapped to the K key.
The default action of K is to do a man page lookup of the word under the cursor. I changed it to grep instead. ... and I preserved the man page functionality too. The default K takes an optional prefix (man page section). I have it so that if I give a numeric prefix to K, it will do the man page lookup for that section:
:nmap K "_y:execute count ? ( ":!man " . count . " " . expand("<cword>") ) : ( ":grep \\<" . expand("<cword>") . "\\>")<CR>
:vmap K "zy:execute ":grep " . getreg("z")<CR>IDEA out of the box has:
- fuzzy text search across your entire codebase. Supports regexes, when you need them
- fuzzy text search for symbols only (e.g. when you only need to search for method names etc.). Supports regexes, when you need them
- fuzzy text search for file names
- Ctrl/Cmd + click, or Ctrl/Cmd + B on any symbol, and you'll get a list of all the places where this symbol is used (e.g. a method name that's called from various places in code, including test code)
No extra plugins, or setting up keybindings, needed.
With vim though... Even discussion on search devolves into listing which tools everyone uses, with which options, and a discussion on how circumvent their limitations.
Edit: esp. with search almost every year there's a new tool that you absolutely must use because it's better than the previous tool. ripgrep, ag, telescope, treesitter, semgrep, use them all!
> Edit: esp. with search almost every year there's a new tool that you absolutely must use because it's better than the previous tool. ripgrep, ag, telescope, treesitter, semgrep, use them all!
Aren't you also doing this? "Use IDEA, it's great for searching!".
I think there's something to be said for aesthetics here, where if you like typing you're gonna be into the grep/ripgrep/find aesthetic, and if you like GUIs you're gonna be into IDEs. People trying to assert some kind of objective superiority of their tools over others' is kind of tedious. Use what you want.
I've rarely had a problem with search, I can type `:grep [some regex]` and I'm quickly shown all matches for that regex in the entire project. I admit I'm not sure how I would do a more complicated query, but this is almost always enough, what kinds of queries do you do which this doesn't cover? There's just one exception, I'm currently working in a codebase where members have very generic names, `Nonce` is a valid field name for a number of different structs, which makes search results for `Nonce` tedious to work through. For this situation I've added a keybinding which calls semgrep and lets me view all references for a specific struct's `Nonce` field.
Calling out to semgrep is an instance of a more general pattern: Because vim is not integrated I lean on tools outside of vim when necessary. The `git` cli, especially once you add some aliases, gives fine access to file history and diffs.
The feature I'm most jealous of is debugger integration. `gdb` and `dlv` get the job done but it's really convenient to be able step through your code with the same interface you use to write it.
> There is also the point of being able to use vim bindings inside of the IDE
Every vim keybinding re implementation I've tried has been missing essential features. When I'm inside an IDE I spend much of my time typing and navigating. When I'm inside vim I'm _thinking_, and the necessary changes occur about as quickly as I decide upon them.