9 ms·

Finding your way in vim: tags, cscope, grep and more

124 points by paweln 15y ago

thristian 15y ago
> A word of caution first: there is no perfect symbol-based navigation for programming languages such as C++ or Java in vim, as vim doesn't perform any syntax analysis of the code. At least for Python, Vim's OmniCompletion does a reasonable job of figuring out function names: http://vimdoc.sourceforge.net/htmldoc/version7.html#new-omni-completion http://vimdoc.sourceforge.net/htmldoc/version7.html#new-omni...
- __rkaup__ 15y ago
  For C and C++, clang_complete gives pretty good completion. https://github.com/Rip-Rip/clang_complete https://github.com/Rip-Rip/clang_complete
  - obiterdictum 15y ago
    I like where this is going, but it was a bit unstable for my taste last I tried it. I think it still relies on the file being syntactically correct, which may break your parsing sometimes and is still quite slow with template-heavy code (Boost mostly). Is it still the case? I'd also like some more build system integration hooks (e.g. provide project-specific include dirs and CXXFLAGS on a per-file basis).
    - __rkaup__ 15y ago
      You can provide your own flags to the compiler, in the g:clang_user_options variable. It does still break in uncompilable code but I don't quite see how that's a problem. It forces you to be more disciplined. If you're finding it a bit slow, the help files do explain you how to set up precompiled headers with it. I haven't tried that though, so I can't comment on how much it helps. Personally, the only times a get annoyed with it are when I type 'catch (...', and it thinks I want it's help.
- pavpanchekha 15y ago
  That's because the whole problem is trivial in Python. What he's talking about is jumping to the correct version of an overloaded function and similar.
- sbochins 15y ago
  Same thing for php. I really don't want to use Eclipse, but its a pain navigating source code using cscope. For instance, if you are looking for a method definition, it may list hundreds of matches. It has no notion of semantic analysis. It doesn't know what class is calling the particular method and if you're looking for something like $instance->execute, you're screwed.
viandante 15y ago
Maybe somebody could help me to figure out how to save files properly with vim. I made a script that opens all the files I need. I call the script with: :source scriptname. Only problem is that the script works only if I open vim with 'vim' and not with 'sudo vim' (by the way, why is that?). But if I open with 'vim', then it give me problem when I try to save...
- drtse4 15y ago
  Hmm, if the script is just a series of open commands it's weird that you are having issues as root (no errors displayed?). With problems when you save you mean that you don't have the required permissions(e.g. files owned by root or other users)? A useful alias if you need root permissions to save: cmap w!! w !sudo tee % >/dev/null
  - _phred 15y ago
    That is a very, very clever little cmap. Added to my .vimrc, thanks!
- thwarted 15y ago
  I made a script that opens all the files I need. I call the script with: :source scriptname. Only problem is that the script works only if I open vim with 'vim' and not with 'sudo vim' (by the way, why is that?). Based on what you've said, I'm not sure if this is an sudo issue or a vim issue. Where is scriptname, and where are the files that scriptname references? Your sudoers may be set up to replace the environment in such a way that vim looks relative to root's home directory rather than your user's home directory. You may need to copy your ~/.vim directory to ~root/.vim, if ~/.vim is where you've put scriptname and the other things it loads. Or you can move these into a system-wide path that vim searches.
  - mcobrien 15y ago
    It might be worth running :cd in the sudo vim instance and in the regular one. Your sudo current directory could well be different to your own which would explain vim not being able to find the script.
deleted 15y ago
[deleted]
lwhi 15y ago
I find VIM so difficult to get my head around. Emacs seems to make more sense.. is there any point in trying to grok VIM?
- _phred 15y ago
  Careful, on this ground holy wars have been fought. http://en.wikipedia.org/wiki/Editor_war http://en.wikipedia.org/wiki/Editor_war The short answer: if you're happy with your productivity in Emacs, then there's likely no compelling reason for you to switch, unless you enjoy the challenge of learning a new text editor.
- donaq 15y ago
  Speaking as a longtime vim user, not if you already grok Emacs. The one really good reason I can think of is that vi is pretty much ubiquitous on *nix and might be better suited if you need a powerful editor which you can almost always expect to be there for you even over ssh.
  - ez77 15y ago
    I know this point has been beaten to death, but in that case you only need to know/grok vi, a significantly smaller subset of vim.
    - seewhat 15y ago
      Granted. Under vi(1), the ctags example in the article is a constructive activity. In the case of cscope, one needs to drive a development session from cscope then drop into vi to make edits.
- pavpanchekha 15y ago
  You should learn VIM for the same reasons a Haskell programmer should learn Common Lisp. Not because you don't already have an extremely powerful tool. Just because there are other extremely powerful tools and the perspective is worth it.
- exDM69 15y ago
exDM69 15y ago
Using cscope, ctags and grep with Vim's location list and quickfix list has been a huge productivity booster for me. I highly recommend experimenting with different key bindings to ease navigating with tags other search results (:cnext :cprev :lnext :lprev, etc).
losvedir 15y ago
tags and cscope look excellent. However, for the grepping and general file searching stuff, wouldn't that be better done from the shell? I generally have both vim (either MacVim, or shell-vim) running, as well as a the command line sitting in a window right next to it. What's the advantage of doing the searching inside vs. outside vim?
- gilgad13 15y ago
  If you search from inside vim, it will load the results into the quickfix list. This means that it jumps you to the first result, and `:cn` and `:cp` will take you to the next and previous results, respectively. This is much easier than searching in a terminal, noting the first filename (which may be buried in some directory), opening it in vim, then jumping/scrolling down to the relevant line.
- iron_ball 15y ago
  Saves a few steps jumping from hit to hit, and if you set up next-result and previous-result mappings, it's even faster. This is assuming your workflow is "find, then open one or more of the results in vim."
- swah 15y ago
  Its faster, because with one key you're searching for the word under the cursor, and you're already on the editor, where the probable next action (editing) on the results is going to be run. Although I would slightly change it to search upwards until finding a .git directory, and from there the recursive grep :)
- ori_b 15y ago
  Vim shells out for that, but it understands the format of results returned by the programs, which makes it easy to jump around in them.

124 points by paweln 15y ago

> A word of caution first: there is no perfect symbol-based navigation for programming languages such as C++ or Java in vim, as vim doesn't perform any syntax analysis of the code. At least for Python, Vim's OmniCompletion does a reasonable job of figuring out function names: http://vimdoc.sourceforge.net/htmldoc/version7.html#new-omni-completion http://vimdoc.sourceforge.net/htmldoc/version7.html#new-omni...

__rkaup__ 15y ago
For C and C++, clang_complete gives pretty good completion. https://github.com/Rip-Rip/clang_complete https://github.com/Rip-Rip/clang_complete
- obiterdictum 15y ago
  I like where this is going, but it was a bit unstable for my taste last I tried it. I think it still relies on the file being syntactically correct, which may break your parsing sometimes and is still quite slow with template-heavy code (Boost mostly). Is it still the case? I'd also like some more build system integration hooks (e.g. provide project-specific include dirs and CXXFLAGS on a per-file basis).
  - __rkaup__ 15y ago
    You can provide your own flags to the compiler, in the g:clang_user_options variable. It does still break in uncompilable code but I don't quite see how that's a problem. It forces you to be more disciplined. If you're finding it a bit slow, the help files do explain you how to set up precompiled headers with it. I haven't tried that though, so I can't comment on how much it helps. Personally, the only times a get annoyed with it are when I type 'catch (...', and it thinks I want it's help.
pavpanchekha 15y ago
That's because the whole problem is trivial in Python. What he's talking about is jumping to the correct version of an overloaded function and similar.
sbochins 15y ago
Same thing for php. I really don't want to use Eclipse, but its a pain navigating source code using cscope. For instance, if you are looking for a method definition, it may list hundreds of matches. It has no notion of semantic analysis. It doesn't know what class is calling the particular method and if you're looking for something like $instance->execute, you're screwed.

viandante 15y ago

Maybe somebody could help me to figure out how to save files properly with vim. I made a script that opens all the files I need. I call the script with: :source scriptname. Only problem is that the script works only if I open vim with 'vim' and not with 'sudo vim' (by the way, why is that?). But if I open with 'vim', then it give me problem when I try to save...

drtse4 15y ago
Hmm, if the script is just a series of open commands it's weird that you are having issues as root (no errors displayed?). With problems when you save you mean that you don't have the required permissions(e.g. files owned by root or other users)? A useful alias if you need root permissions to save: cmap w!! w !sudo tee % >/dev/null
- _phred 15y ago
  That is a very, very clever little cmap. Added to my .vimrc, thanks!
thwarted 15y ago
I made a script that opens all the files I need. I call the script with: :source scriptname. Only problem is that the script works only if I open vim with 'vim' and not with 'sudo vim' (by the way, why is that?). Based on what you've said, I'm not sure if this is an sudo issue or a vim issue. Where is scriptname, and where are the files that scriptname references? Your sudoers may be set up to replace the environment in such a way that vim looks relative to root's home directory rather than your user's home directory. You may need to copy your ~/.vim directory to ~root/.vim, if ~/.vim is where you've put scriptname and the other things it loads. Or you can move these into a system-wide path that vim searches.
- mcobrien 15y ago
  It might be worth running :cd in the sudo vim instance and in the regular one. Your sudo current directory could well be different to your own which would explain vim not being able to find the script.

deleted 15y ago

[deleted]

lwhi 15y ago

I find VIM so difficult to get my head around. Emacs seems to make more sense.. is there any point in trying to grok VIM?

_phred 15y ago
Careful, on this ground holy wars have been fought. http://en.wikipedia.org/wiki/Editor_war http://en.wikipedia.org/wiki/Editor_war The short answer: if you're happy with your productivity in Emacs, then there's likely no compelling reason for you to switch, unless you enjoy the challenge of learning a new text editor.
donaq 15y ago
Speaking as a longtime vim user, not if you already grok Emacs. The one really good reason I can think of is that vi is pretty much ubiquitous on *nix and might be better suited if you need a powerful editor which you can almost always expect to be there for you even over ssh.
- ez77 15y ago
  I know this point has been beaten to death, but in that case you only need to know/grok vi, a significantly smaller subset of vim.
  - seewhat 15y ago
    Granted. Under vi(1), the ctags example in the article is a constructive activity. In the case of cscope, one needs to drive a development session from cscope then drop into vi to make edits.
pavpanchekha 15y ago
You should learn VIM for the same reasons a Haskell programmer should learn Common Lisp. Not because you don't already have an extremely powerful tool. Just because there are other extremely powerful tools and the perspective is worth it.
exDM69 15y ago

exDM69 15y ago

Using cscope, ctags and grep with Vim's location list and quickfix list has been a huge productivity booster for me. I highly recommend experimenting with different key bindings to ease navigating with tags other search results (:cnext :cprev :lnext :lprev, etc).

losvedir 15y ago

tags and cscope look excellent. However, for the grepping and general file searching stuff, wouldn't that be better done from the shell? I generally have both vim (either MacVim, or shell-vim) running, as well as a the command line sitting in a window right next to it. What's the advantage of doing the searching inside vs. outside vim?

gilgad13 15y ago
If you search from inside vim, it will load the results into the quickfix list. This means that it jumps you to the first result, and `:cn` and `:cp` will take you to the next and previous results, respectively. This is much easier than searching in a terminal, noting the first filename (which may be buried in some directory), opening it in vim, then jumping/scrolling down to the relevant line.
iron_ball 15y ago
Saves a few steps jumping from hit to hit, and if you set up next-result and previous-result mappings, it's even faster. This is assuming your workflow is "find, then open one or more of the results in vim."
swah 15y ago
Its faster, because with one key you're searching for the word under the cursor, and you're already on the editor, where the probable next action (editing) on the results is going to be run. Although I would slightly change it to search upwards until finding a .git directory, and from there the recursive grep :)
ori_b 15y ago
Vim shells out for that, but it understands the format of results returned by the programs, which makes it easy to jump around in them.