How I boosted my Vim(nvie.com)
nvie.com
How I boosted my Vim
http://nvie.com/posts/how-i-boosted-my-vim/
68 comments
So you can't type sdf in your code?
You can type it... Just slowly
My combination is just kj.
My combination is just kj.
I have jj in my .vimrc.
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 use ;;
Not a lisp programmer, I take it.
I'm less learned: the first thing I thought was case branches in Bash scripts.
This would suck if one is also Dutch. We have kj appear rather frequently in words.
ctrl-[ is also equivalent to Esc
weird
I use <C-j> in insert mode (not to be confused with <C-j> in command mode, which jumps to the buffer below).
I use <C-j> in insert mode (not to be confused with <C-j> in command mode, which jumps to the buffer below).
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).
Obviously, these are only my personal opinions.
Obviously, these are only my personal opinions.
I use the ViEmu plugin for Visual Studio. It makes for an awesome environment.
http://www.viemu.com
http://www.viemu.com
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.
What features do you think Emacs is missing?
What features do you think Emacs is missing?
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.
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.
Emacs does this too: http://github.com/jrockway/eproject.
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?)
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.
Emacs does this too: http://github.com/jrockway/eproject.
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.
> I suspect you can't beat Java on Eclipse
You can: IntellJ.
You can: IntellJ.
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.
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.
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.
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.
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.
> 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.
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.
You're not suggesting Emacs or Vim is somehow better, are you?
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.
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 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 :)
I was really expecting to see a link to his git repo in the end.
Oops, that was lame. I have added the link to the end of the blog post. Thanks for noticing.
Cheers, Vincent
Cheers, Vincent
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.
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.
or just do:
set backupdir=./.backup,.,/tmp
set directory=.,./.backup,/tmp
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.
(http://vim.wikia.com/wiki/Remove_swap_and_backup_files_from_...)
set backupdir=./.backup,.,/tmp
set directory=.,./.backup,/tmp
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.
(http://vim.wikia.com/wiki/Remove_swap_and_backup_files_from_...)
set backupdir=~/.vim/backup//
set directory=~/.vim/swp//
Oh man, this is awesome. Too bad it's vim-specific and not a shell built-in, which would be handy.
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.
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.
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.
Until it saves your ass. Which will happen, if you use vim for a few years.
You can configure it to put your swap files in a canonical dir, instead of polluting the directory you're editing files in:
set backupdir=/var/tmp,/tmp
set directory=/var/tmp,/tmp
Now you can just nuke the swap files in one swoop:
rm -rf /var/tmp/*.swp
You can configure it to put your swap files in a canonical dir, instead of polluting the directory you're editing files in:
set backupdir=/var/tmp,/tmp
set directory=/var/tmp,/tmp
Now you can just nuke the swap files in one swoop:
rm -rf /var/tmp/*.swp
Or cron-job the pruning.
Swap files can save you from editing the same file in two vim instanstances as once. Possibly overwriting each other.
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.
> vim can crash
It can?
It can?
Never had vim crash, but I've had the OS crash. Or X server. Better safe than sorry.
yes, i've had it crash once in a rare while.
Vim: Caught deadly signal SEGV
Vim: Caught deadly signal SEGV
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.
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.)
sweet!)
(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.)
sweet!)
In the recent years the booster for me has been the "Command-T" plugin, which makes it super fast to open files.
I can _highly_ recommend this plugin, even if it's a bit harder to install than most other Vim plugins.
Check out https://wincent.com/products/command-t and http://amix.dk/blog/post/19501#Command-T-for-Vim-an-awesome-...
I can _highly_ recommend this plugin, even if it's a bit harder to install than most other Vim plugins.
Check out https://wincent.com/products/command-t and http://amix.dk/blog/post/19501#Command-T-for-Vim-an-awesome-...
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.
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.
I used to be a die-hard NERDTree user until I discovered CommandT. It is solid gold and I couldn't imagine using vim without it.
How is it better than (or different from) http://github.com/tomtom/tselectfiles_vim which is vimscript only?
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.
And for people who can't seem to find just the right colour scheme: Color Scheme Pack plugin (http://www.vim.org/scripts/script.php?script_id=625). It has over a 100 different themes, nicely categorized.
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.
And for people who can't seem to find just the right colour scheme: Color Scheme Pack plugin (http://www.vim.org/scripts/script.php?script_id=625). It has over a 100 different themes, nicely categorized.
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:
jkjk is also a sequence I've seen used.