Oh, and man… never ever let Vim write a backup file! They did that in the 70’s. Use modern ways for tracking your changes, for God’s sake.
set nobackup
set noswapfile
backup files are one thing, but turning off swap files is a terrible idea. vim can crash, you can accidentally close the window, your ssh session can die, etc. if you exit vim cleanly then the swap files will be transparent, so i don't see the point in disabling them.
This way, if you want your backups to be neatly grouped, just create a directory called '.backup' in your working directory. Vim will stash backups there. The 'directory' option controls where swap files go. If your working directory is not writable, Vim will put the swap file in one of the specified places.
the minute I've read it I went and set the noswapfile option. I don't care if vim crashes, I save all the time. if it crashes I will just repeat the last edit. The stale swapfiles etc has caused me more time wasted over the years then lost edits.
But, I soon realized that noswapfile has another problem which caused me to disable it after all: it will allow you to open same file in more then one vim editor instance. And this is really asking for troubles.
It is less of a problem with graphical vim as you can use "autoread" to sync changes between instances, but it is a disaster on console.
I too very much happy after getting these two option. By looking those swap file and backup file I started hating vim. Why on earth it is creating all the un-necessary stuffs (though they useful at some case). Now for newbie like me I love this tips :)
so far, swap files have caused me more headache than anything else. I'm a paranoid maniac and I save every minute or two, so worst case I'll repeat a minute worth of coding.
What really ends up happening is I try to edit a file and something annoying pops up telling me about something requiring my attention (swap file already exists .. read only mode .. bla bla). In other words, it's just a distraction, most of the time.
Screen can help with the accidental closing of a window or a dropped ssh session. You can even restart X and just reattach to the daemon when you log back in.
Great guide! My .vimrc had most of these settings, but I picked up a few things that made life much easier. Below are some tricks that I use which might make useful additions.
Binding the <Esc> key to capslock has been really useful for me. http://vim.wikia.com/wiki/Map_caps_lock_to_escape_in_XWindow... explains how you can do this, although it's done externally and not in Vim. Just include the script in your shell rc file and you're good to go.
Experienced users can hide the menu and tool bars with:
set guioptions-=m "remove menu bar
set guioptions-=T "remove toolbar
Extra screen space for your code is always nice!
Another amazingly useful plugin is MiniBufExplorer (http://www.vim.org/scripts/script.php?script_id=159). This allows you to open multiple buffers in the same vim window, and with the key binds given in the plugin page you can switch between buffers just like you switch between tabs in Firefox. It's really useful when you follow tags in a large source directory.
One thing that continues to impress me is how much bigger than popular belief Vim is. There is a plethora of options you can set in your vimrc file (just now I found out about wildignore, and I'm kind of a Vim addict) and there are fucking lot of commands (try [I ), and that's not considering Ex mode.
Customization is way easier than in Emacs, you just unzip an archive in your .vim dir and (99% of the time) it works. I have plugins that do everything I've seen in Emacs that has to do with code, and then some.
Vim is no more the tiny start-quick-edit-close editor that it used to be.
Edit: I don't want to start a holy war here. Emacs is great, and I in fact have it opened right now. It's just that it's supposed to be able to do amazing stuff that Vim can't, I'm saying that that's probably still true, but to a way lesser level than before.
thank you for making '[I' my hey-i-learned-a-neat-thing-of-the day!
(from the doc, [I:
Display all lines that contain the keyword under the cursor. Filenames and line numbers are displayed for the found lines. The search starts at the beginning of the file.)
I've gotta second this, command-t is probably my single favorite plugin. I tried using FuzzyFinder way back when, but it was just a little too quirky to be useful. This blows FuzzyFinder (and even fuzzyfinder_textmate) out of the water.
Navigating you project in this way feels a lot quicker than actually browsing the hierarchy with something like NERDTree. Don't worry about where things actually are, just type some junk and the file you want will almost always come to the top.
This is actually a really good guide. I use vim daily at work, and my .vimrc shares most of these settings.
One big productivity boost for me was remapping the Escape key to something a little more convenient. I just remapped the ESC key altogether, but this can throw you off if you find yourself working at lots of different computers. If you prefer something less permanent, you can map a key sequence to ESC. I like this one, which maps 'sdf' to ESC if you're in insert mode:
I typically just remap the escape key to capslock at the OS level. Even though it can through you off like you said, I still find it more convenient than key walks to generate an escape.
vf is the easiest-to-type two-letter sequence i could find that doesn't appear in any english word. other languages' mileages may, of course, vary. (and if some chavfucker wants to object, well...)
I have a similarly hacked up Emacs environment and it's actually gotten to the point that I'm taking a hard look at IDEs again. Having all this functionality available in a single integrated package with a visual debugger thrown in is starting to look strangely appealing.
IMO, IDEs are better for almost everything, except for actual text editing. For that, vim and emacs are still the best (I prefer vim for plain text editing prowess, but emacs has a lot of other goodies which make it closer to an IDE, but still not as good).
I agree. If I'm just editing text, like an email or a readme or a blog post or a typical config file, I'd rather have a quick, lean, dedicated text editor. Some of these editor-as-IDE environments start to feel a little like an incredibly pimped-out Pinto though.
IMO, the problem isn't with "just editing a quick file" or not.
The problem is, IDEs are amazing for everything other than editing text. This includes editing source code, mind you. I find it much easier and funner to edit code in vim, since it has so many small things that make editing code much faster.
IDEs are generally much slower for the actual act of editing code than things like vim. They're just better because of everything else they do, which (sometimes) makes up for it.
Also, most people care a lot more about all the other things like code completion than they do about the small improvement you can get by editing in vim/emacs.
Define most people. Personally I spend the majority of my day editing text, so the small improvements are pretty important.
P.S. I have code completion, jump to file etc all working just fine in vim. On a codebase with 15000+ files, this is a hell of a lot faster in vim than it is in say, Eclipse.
I agree that this is true, if you have no desire to learn how Emacs and your chosen modes work. If you are willing to dig in, the ability to fix your tools with a simple C-M-x is indispensable, and is a feature that no IDE has.
Firstly, emacs is not a quick-start environment. If I want to get started in a new language, let's say Java, downloading Eclipse will make getting started with Java insanely easy. The same with C++ and Visual Studio. Compare with emacs, in which I have to spend time getting things to work. I'm not saying it's worse in the long run (although I suspect you can't beat Java on Eclipse), but the overhead every time I want to try something new is large.
But the biggest problem with emacs is the "project management" functionality. Emacs is designed to be "just an editor". To do the most simple thing, which is to define a project consisting of a few directories, and be able to move between those files, is very hard. Pick up many modern editors, and you can, with one command, point to a directory and have a project tree, a "jump to file", etc, all built for you. Not to mention the way they create makefiles automatically, do code-completion, create tag files so you can jump to a function by name, etc.
I can just list the number of things I didn't have to know about before starting emacs: makefiles, tag files, etc. Not having to worry about these kinds of things is the biggest feature emacs is lacking.
Makefiles are an acceptable barrier to entry. I've lost a lot of hair trying to figure out how to build huge Java projects that the developers just built inside their five-major-versions-old IDE. ("Oh, just build it by clicking the 'export to WAR' button and then copy the file to each production server." No.)
Considering how trivial it is to write an ant file to do the same thing, it's appalling that the IDEs don't just do this by default. How can you write a good application if you don't even know how to compile it?
But the biggest problem with Emacs is the "project management" functionality. Pick up many modern editors, and you can, with one command, point to a directory and have a project tree, a "jump to file", etc, all built for you.
Of course, Emacs' version is a lot more flexible. The user can hook it, so he gets a fresh project REPL the first time he visits a new project. Or, he can hook the eproject-after-save hook, and commit the changes to a "backup" git branch, so that he never has to worry about not being able to undo.
The idea behind Emacs is that it can do things that nobody else has ever done before, and it continually lives up to this expectation.
(Also, "this is too hard for beginners". OK. Then how did I learn Emacs?)
It's not that Emacs or vi are lacking the features of an IDE, is that they were not designed to be one. If you want to make vim or Emacs an IDE you can, but it is not easy.
yep, back when i had a job coding under windows, i used to use gvim for text file editing, but visual studio for compiling, debugging and the really good search utilities.
> Having all this functionality available in a single integrated package...
s/available/trapped/
s/integrated/monolithic/
;-)
I think IDEs are useful, yet they always make me think what a bad example of code reuse they are. Code reuse? Are you kidding? Much better rewriting each plugin with each IDE ;-)
EDIT: By "monolithic" I don't mean that IDEs are not modular; I mean you can't use their modules elsewhere.
Emacs and Vim are as good as the tools they can build upon, just like Eclipse is as good as available plugins. If you are going to develop in Erlang or Common Lisp, chances are Emacs is the best free IDE around (I don't know about Vim). It isn't so if you are going to develop in Java.
There is a lot of wheel reinventing in the Emacs and Vim's camps too, however. I just wanted to say that no matter how much code reuse is valued by developers, the tools they use the most are made with the less reusable pieces of software around.
I have a similarly hacked up IntelliJ environment (with IdeaVim and other things) and it's actually gotten to the point that I'm taking a hard look at Emacs again. Having all this functionality available in a single integrated package with a visual debugger thrown in is starting to look strangely appealing.
I am always thinking.. instead of downloading installing plugin here and there.... can some experienced programmer or vim expert create one full package which is best for atleast one programming language for e.g., Ruby and Ruby on Rails. So that newbie can like it. Newbie actually means who spent months and years on vim but never able to make their primary editor :)
Another great trick I read in a reddit comment is to use <C-r>+ to paste right from the OS paste board. Of course, this only works when running Vim locally (i.e. not over an SSH connection).
Actually, it does work over SSH if your X connection is forwarded properly.
set nobackup set noswapfile
backup files are one thing, but turning off swap files is a terrible idea. vim can crash, you can accidentally close the window, your ssh session can die, etc. if you exit vim cleanly then the swap files will be transparent, so i don't see the point in disabling them.