files with the .c extension for the substring "foo". The
arguments to :grep are passed straight to the "grep" program, so you can use
whatever options your "grep" supports.
By default, :grep invokes grep with the -n option (show file and line
numbers). You can change this with the 'grepprg' option. You will need to set
'grepprg' if:
a) You are using a program that isn't called "grep"
b) You have to call grep with a full path
c) You want to pass other options automatically (e.g. case insensitive
search.)
Once "grep" has executed, Vim parses the results using the 'grepformat'
option. This option works in the same way as the 'errorformat' option - see
that for details. You may need to change 'grepformat' from the default if
your grep outputs in a non-standard format, or you are using some other
program with a special format.
Once the results are parsed, Vim loads the first file containing a match and
jumps to the appropriate line, in the same way that it jumps to a compiler
error in |quickfix| mode. You can then use the |:cnext|, |:clist|, etc.
commands to see the other matches.
5.4 Using :grep with id-utils
You can set up :grep to work with the GNU id-utils like this: >
:set grepprg=lid\ -Rgrep\ -s
:set grepformat=%f:%l:%m
then >
:grep (regexp)
works just as you'd expect.
(provided you remembered to mkid first :)
5.5 Browsing source code with :vimgrep or :grep
Using the stack of error lists that Vim keeps, you can browse your files to
look for functions and the functions they call. For example, suppose that you
have to add an argument to the read_file() function. You enter this command: >
:vimgrep /\<read_file\>/ *.c
You use ":cn" to go along the list of matches and add the argument. At one
place you have to get the new argument from a higher level function msg(), and
need to change that one too. Thus you use: >
:vimgrep /\<msg\>/ *.c
While changing the msg() functions, you find another function that needs to
get the argument from a higher level. You can again use ":vimgrep" to find
these functions. Once you are finished with one function, you can use >
:colder
to go back to the previous one.
This works like browsing a tree: ":vimgrep" goes one level deeper, creating a
list of branches. ":colder" goes back to the previous level. You can mix
this use of ":vimgrep" and "colder" to browse all the locations in a tree-like
way. If you do this consistently, you will find all locations without the
need to write down a "todo" list.
=============================================================================
6. Selecting a compiler *compiler-select*
*:comp* *:compiler* *E666*
:comp[iler][!] {name} Set options to work with compiler {name}.
Without the "!" options are set for the
current buffer. With "!" global options are
set.
If you use ":compiler foo" in "file.foo" and
then ":compiler! bar" in another buffer, Vim
will keep on using "foo" in "file.foo".
The Vim plugins in the "compiler" directory will set options to use the
selected compiler. For `:compiler` local options are set, for `:compiler!`
global options.
*current_compiler*
To support older Vim versions, the plugins always use "current_compiler" and
not "b:current_compiler". What the command actually does is the following:
- Delete the "current_compiler" and "b:current_compiler" variables.
- Define the "CompilerSet" user command. With "!" it does ":set", without "!"
it does ":setlocal".
- Execute ":runtime! compiler/{name}.{vim,lua}". The plugins are expected to
set options with "CompilerSet" and set the "current_compiler" variable to the
name of the compiler.
- Delete the "CompilerSet" user command.
- Set "b:current_compiler" to the value of "current_compiler".
- Without "!" the old value of "current_compiler" is restored.
For writing a compiler plugin, see |write-compiler-plugin|.
Use the |compiler-make| plugin to undo the effect of a compiler plugin.
CPPCHECK *quickfix-cppcheck*