Finding your way in vim: tags, cscope, grep and more(stolowski.blogspot.com)
stolowski.blogspot.com
Finding your way in vim: tags, cscope, grep and more
http://stolowski.blogspot.com/2011/07/finding-your-way-in-vim.html
6 comments
For C and C++, clang_complete gives pretty good completion.
https://github.com/Rip-Rip/clang_complete
https://github.com/Rip-Rip/clang_complete
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).
I'd also like some more build system integration hooks (e.g. provide project-specific include dirs and CXXFLAGS on a per-file basis).
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.
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.
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.
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...
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...
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
A useful alias if you need root permissions to save:
cmap w!! w !sudo tee % >/dev/null
That is a very, very clever little cmap. Added to my .vimrc, thanks!
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.
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.
You might try using sessions instead.
In my vimrc, I have this line:
nnoremap <Leader>q :mks!<CR>:qall!<CR>
alias vv=vim -S
[deleted]
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?
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?
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.
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.
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."
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 :)
Although I would slightly change it to search upwards until finding a .git directory, and from there the recursive grep :)
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.
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).
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?
Careful, on this ground holy wars have been fought.
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.
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.
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.
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.
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.
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.
I have not used Emacs, but Vim feels incredibly powerful to me. I feel that I can tell it what to do in a very natural way: "change inside parentheses", or "delete from here to the word 'foo'," or "replace 'bar' with 'baz' inside the current set of curly braces."
Most of my time in code is spent moving around, editing and refactoring. Vim fits that: "Normal" mode puts an entire keyboard of commands at my disposal for for moving around and editing - no need to press Control or something to say "watch out, I'm going to issue a command!" Of course I am - that's what I mainly do. If I actually want to type, I go into insert mode.
I have written the beginnings of a book to explain the power of Vim, if you'd like to check it out. I'd love any feedback anyone wants to give.
http://nathanmlong.com/vanquish/
Most of my time in code is spent moving around, editing and refactoring. Vim fits that: "Normal" mode puts an entire keyboard of commands at my disposal for for moving around and editing - no need to press Control or something to say "watch out, I'm going to issue a command!" Of course I am - that's what I mainly do. If I actually want to type, I go into insert mode.
I have written the beginnings of a book to explain the power of Vim, if you'd like to check it out. I'd love any feedback anyone wants to give.
http://nathanmlong.com/vanquish/
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.
My experience is this: Emacs has better integration to tools (like debuggers, etc).
However, I like the Vim input model, where you combine commands (like delete or yank) to a motion (like a word, 3 words or everything inside these parentheses).
Emacs has the Viper mode, which gives basic Vi-style input model but it doesn't do advanced stuff like text objects.
IMO any serious coder should try both, Vim and Emacs and see which one works better.
However, I like the Vim input model, where you combine commands (like delete or yank) to a motion (like a word, 3 words or everything inside these parentheses).
Emacs has the Viper mode, which gives basic Vi-style input model but it doesn't do advanced stuff like text objects.
IMO any serious coder should try both, Vim and Emacs and see which one works better.
I have next to no experience with Emacs so from the perspective of a 'normal' text-editor-using-guy Vim is (Warning, some slight exaggeration ahead) one of the greatest things I have discovered, learnt and now use daily.
Why? I can do simple things faster (Delete a single char, delete a line, search/replace, etc.), it seems like a more logical way to write, and so on.
Why? I can do simple things faster (Delete a single char, delete a line, search/replace, etc.), it seems like a more logical way to write, and so on.
Wow. I've been down-voted for asking a question.
EDIT: Please, keep going if you really feel that vindictive.
EDIT: Please, keep going if you really feel that vindictive.
I assume it's because your original question, vi/vim vs. emacs is a decades old flamebait question, and it probably seems unlikely to some people that anyone could become a proficient emacs user and end up on Hacker News without ever encountering at least the jokes about vim vs emacs holy wars.
I increasingly see posts on HN about vim, rather than emacs. I like emacs, but wonder whether it's worth trying to use vim instead of emacs. I honestly couldn't give a damn whether some nerds like to get their knickers in a twist re. which editor is best.
[deleted]
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...