> 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:
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).
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.
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:
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.
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.
You might try using sessions instead.
In my vimrc, I have this line:
nnoremap <Leader>q :mks!<CR>:qall!<CR>
And in my .bashrc I have this line:
alias vv=vim -S
Once you have all the files you want open and arranged the way you like, save it all and then hit \q to save the session and quit. Then, instead of vim, use vv to go right back to your session. That's how I do it, anyway.
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.
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 :)
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).
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.
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.
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.
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.
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.
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.
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...