Can you show me with a short screencast why vim is superior? And, why it is worth spending the time to learn, not only mentally and visually, but also mechanically with my hands.
Thanks.
It's pointless to compare vim, atom, and eclipse in the same thought process because they're completely different tools for different tasks.
> ... as to why vim is superior
Vim is not superior categorically. If you expect your editor to autocomplete Java code for you and fill in imports and look up methods for you, and have extra features that aren't even connected to editing, Eclipse is tremendously better. But Eclipse is a different tool. It's a full IDE.
Atom is a gui-based editor.
Vim is a cli-based editor.
I've been seeing people left and right comparing editors as if there were some definitive lockdown about to happen that binds you to a single editor. Use whatever you like and what gets your job done. You can also use more than one for more than one task.
I use vim when I'm editing files via ssh remotely, Sublime when I'm editing local files, and VS Pro when I'm working with .NET at work, because these are, respectively, my tools of choice for these tasks.
None are "better" or "worse". They're just different.
When I was in high school, I bragged to my dad about typing something like 110 words per minute. He said… that's nice; I can type 1100 words per minute. Incredulously, I asked him to show me. He fired up his vim setup, opened a few files, started a new one, and sure enough in under 60 seconds he had a ~1100 "word" Sybase stored procedure (or something) written.
Of course he didn't literally type all of it. Of course it was a loooot of copy pasta, and the whole thing was tongue-in-cheek. But it was a good example of what you can do with Vim given the right scenario.
Most of what was demonstrated was Vim's superior capacity for jumping around to the correct place in your file precisely and quickly, which doing with a mouse is a nightmare.
For example, to copy 3 lines from the cursor position and paste them 5 lines earlier:
3Y :-5 p
(and there are faster ways, some people are wizards)
I also do relative numbering in my vim (I have the current line labelled as 0, the line above it -1, etc) so that I can move around relative to the cursor without having to count lines. You can also do absolute numbering but I find that tedious when you have large files.
changed my life, now when I'm in ssh I can just "rsub this.txt" and it pops up in my currently running sublime window !
vim/emacs. Once you get up to speed, you can type or move around faster than with other editors. The main reason to use these are because you're already spending most of your time in the terminal because you're a) working in an ecosystem like rails where most of the tooling is run from the terminal b) doing sysadmin tasks like editing config files, running ansible or otherwise writing code over ssh. That's the sweet spot. Once you become comfortable there are ways to extend the editors to basically give them ide-like functionality.
Gui-based text editors like Atom, Notepad++, etc. These are the simplest editors to get up and running and have a low level of bloat. You usually don't need to spend time waiting for it to load whereas most IDEs take 1-5 minutes to load up fully. The main reason to use these is ease of use. If you don't need the complexity of vim or an ide, use this.
IDEs work best when you are dealing with large codebases, especially if you're not familiar with the codebase or the available functions. I personally maintain ~600k lines of mostly undocumented code at work. It uses a custom framework and was contributed to by dozens of developers. There an IDE is probably the best choice because it will catch errors (made by you or past developers), it will autocomplete function names and best of all, there is a jump to definition feature so you can quickly trace through code paths. After two years of working here I can use vim without too much of a dropoff
With that said, there are also plugins for many editors that make vim commands work in them. Which is a nice compromise if you like GUIs.
It's the actual awareness of code you've previously written, the detection of possible issues before you compile--IDEs tend to read your code with you and help out a lot in many more ways... I suppose it's not "autocompletion" but I was hoping to successfully use that as an umbrella term.
Take it with a grain of salt, though. There are 3 (that I can find) Java auto-complete plugins for Vim and I have no idea if any of them are good. (I don't develop in Java often and when I do it's trivial code so I haven't had a chance to try them)
Interviews of vim programmers - http://howivim.com/
Gary Bernhardt's screencast on - https://www.destroyallsoftware.com/screencasts
Play through the first few levels and it becomes apparent why people like vim; you can move around a text file incredibly quickly, a mouse is slow and dumb by comparison.
That being said, I've recently started picking up an interest in lisp (currently slowly making my way through sicp), and I've seen indications that Emacs is somehow more suited to lisp development than vim. As a result, I've actually been considering switching back again, despite emacs pinky, although I'm still on the fence about this.
If anybody here has some knowledge about what Emacs offers in terms of lisp development that vim doesn't (or vice versa) and/or has some good references, I would be very interested to know.
The beauty of emacs is that it is extremely customizable. spacemacs features a full fledged vim emulation mode that does a great job of feeling like vim.
As far as lisp development goes, the reason for emacs being a "better" environment is that it is implemented in a flavour of lisp, so you see a lot of great packages (paredit/smartparens, SLIME, to name a few) built with lisp in mind. Plus you will be editing your config file in lisp.
I've personally gone through phases of using vim, emacs, notepad++, Visual Studio, and (currently) SublimeText and xcode. My opinion is that the editor is never the "bottleneck" with programming speed, so just use whatever is the most comfortable for you. One nice thing about vi/vim is that some variant of it is installed almost everywhere so you're always likely to have a usable editor available if you learn it.
The tongue in cheek answer: My ability to code quickly is held back by my ability to create code structures in my mind, not type code into an editor.
I appreciate vim not because it's faster, but because I don't have to think about using a mouse, and I can just have a conversation with the editor.
"Correct inside these parenthesis" ci(
"Insert the text 'func Something() error {'"
"Delete three lines and paste them above the current line" 3ddP
"Goto the definition" gd
"Go back" C-o
"Write to disk and quit" :wq
It is easy for me, and not a lot of typing. I log on a server, and type vi program.py. Now I am in normal mode at the top of the file. If I want to go to line 80 I type 8-0-return. If I want to search for a list called dataList below that I type /dataList and return. If I want to go to the bottom of the file I type G. If I want to go back to the top of the file I type 1G. It is economic with how much typing you need to do. It loads up quickly. It also uses the same commands as ed in case you're on a dumb terminal, although that tends to be rare nowadays.
If I'm doing a lot of multi-window stuff, or cutting and pasting from the middle of a line to the middle of another line 3000 lines down or something complex I use Emacs. For example, emacs has a command 'keep-lines' where only lines matching a regex get kept (or flush-lines where all lines matching a regex get deleted). Vi can do more complex stuff but I usually just switch to emacs when things get complicated.
Speaking of speed - if you look at the old e-mails and Usenet posts and such from Bill Joy on the net, you may notice he did not capitalize any letters when he wrote. That saved him the time of having to hit the shift key.
You will find a version of vi on almost any UNIX-ish system you're likely to find running. It's an incredibly robust and battle-tested editor which can help you out of tight situations.
Nano isn't so bad and is fairly common now, but its' predecessor, Pico, was absolutely terrible for editing code. Pico was originally the editor bundled with the Pine e-mail client, and it had a nasty habit of chopping lines of text at 80 characters wide. I once used Pico to edit a hundreds-of-lines-long apache config, bungled the whole thing, and had to manually reconstruct it with vi.
At the time, I was a fairly new employee in my first tech job as support for a Linux distributor in the 90s and our build engineer fairly quickly informed me that it was time I learn vi.
Any system with vim installed on it - including a fresh Mac - will have vimtutor, which I highly recommend everyone spend a half hour with. When I taught Linux admin courses, I had everyone run through this at lunch on the first day to help them avoid the professional embarrassment I had. ;)
[Edit: and I second what everyone else says about it not necessarily being a supreme development experience. I use a Mac with, over the years, TextMate, Sublime, Light Table, and now Atom. Some people make a convincing argument that Emacs is a supreme dev environment, but I've never quite picked it up]
I'm a long-time vim user, but it's at least worth confronting the criticisms head on (even if this one is a bit tired).
For modern development I wouldn't compare vim (a text editor) to Eclipse (an IDE). I'd say learn vim if you think you might ever find yourself in a shell needing to do things. No Xwindows and maybe not even emacs. I personally use vim for everything I do but, that's because I've used it for 21 years now. The second reason is I develop by always taking the easiest path (kiss theory) and generally don't need an IDE for most things. The third reason is that I started developing carpel tunnel in my right hand using the mouse and decided to not use a mouse as much as possible.
I also have struggled with mouse-related RSI. Switching to trackballs helped a ton for me.
Switching to Vim completely eliminated those issues for me.
As a happy bonus I gained access to a lot of Vim tricks... Normal mode is basically a weird programming language, which makes it enormously powerful, particularly for repetitive tasks. And Vim macros are magical as a consequence.
Which is why when using VS or IntelliJ I adopt Vim emulation plugin of some kind. None are perfect but most are sufficient to allow me to continue to use my Vim muscle memory in more integrated environments.
Vim in particular is a philosophy of keybindings. It has a syntax and a logic to it. For example `daw` will delete a word. To delete a sentence you would `das`. Guess what you would use to delete a paragraph? Once you "grock" vim logic you can perform more complex actions without much cognitive overhead and with your fingers on the home row. Writing in Vim gives me a feeling of mastery and fluidity with the machine I have not felt since my competitive gaming days.
Huh. I use 'dw' and 'dl'. Why the extra key?
Using 'daw' deletes the whole word "around" the cursor (hence 'a' command) - meaning you don't have to pay attention to the cursor position, it could be on the start/middle/end of the word and the result would be the same.
See http://vimdoc.sourceforge.net/htmldoc/motion.html#object-mot...
and
The equivalent in any Mac OS X text editor is:
alt-left-shift-right-backspace.
Another good reason to go with vim is that it will probably be around when other editors may become abandoned. Sure it's good with many editors to pick from, but most of us go for the latest shiny thing and it's always a learning curve even going between Sublime and Atom.
It's free, you can install it on anything. It's not the crazy commands that makes it fast really.
I would literally like to see how fast coding in vim is. Can anyone point me to a screen capture of editing in vim? I've always been skeptical how editing without a mouse could be fast.
Edit: I just noticed that he is asking for a screencast. Why is everyone ignoring that request?
All of the editors you've mentioned are very good at what they do, some might be better in certain areas than others.
Dvorak or similar will result in a typing speed improvement, and some physical benefits, but typespeed is rarely the limiting factor when coding.