7 ms·

I have a hard time understanding vim users. All the cool features listed in this article exist in any modern text editor. I personally use Notepad++, but I'm su

I have a hard time understanding vim users. All the cool features listed in this article exist in any modern text editor. I personally use Notepad++, but I'm sure the same goes for Textmate, Sublime Text and many others. The only advantage I can see in Vim over a modern solution is that it runs in the terminal (which I guess is useful if you like to remotely modify files in your production environment?). Is it that after they have spent so many years learning the arcane controls, users feel obligated to stick with it in order to justify all the time they've already invested? I must say I've only spent ~2 months of my life using vim before giving up, which I think is already pretty long for an evaluation. I have never experienced or even witnessed the productivity gains you're supposed to get from mastering vim. All I've seen is very unintuitive shortcuts for Ctrl+Backspace advertised as unique features in the world of text editing. I would be very happy if someone could point out to me the elephant that I am not seeing here.

Alupis 12y ago
> I personally use Notepad++ Vim is a Linux/Unix text editor used via the terminal. Notepad++ is for the Windows GUI environment. Apples and Oranges. Why is a good terminal text editor important? When you are SSH'ed into your server and you need to adjust a configuration file, you require a good terminal text editor. It also is very good for C programming, and a lot of C programmers use it extensively. There are many other reasons. From a Windows GUI environment, you won't really be able to compare or relate, or understand why vim is so good.
- cageface 12y ago
  I know Vim well enough to use it for this kind of thing but, IMO, if you find yourself doing a lot of hot edits on live servers you're doing it wrong. Almost all of the editing I do is in a consistent environment on my development machine and I don't see the point of using a lowest-common-denominator tool when I don't have to. I'm sure with some work you can bend Vim into something approaching the power of an IDE but why would you bother? Text editing is a pretty small part of the work of development, after all.
  - wyclif 12y ago
    Text editing is certainly a small part of development, but if you're in a dev role where your job involves writing a lot of code, you actually are spending a lot of time in editing mode. I spend quite a lot of time in Vim now because I'm doing a lot of programming, and that's why it's worth spending the time to both learn Vim and configure it to taste. Most of the time what I need to get the job done is a great text editor, and Vim scratches that itch. If, for instance, I was doing massive code refactoring instead I can see why an IDE would be the right tool to use.
- pmoriarty 12y ago
  Actually, vim is a cross-platform editor. You can use it on Linux, MacOS, and Windows (among many other operating systems). vi is even more ubiquitous. Even if one doesn't use vim as one's primary editor, it would behoove one to learn the basics of vi, as it's available on virtually every operating system.
- cbd1984 12y ago
  > Vim is a Linux/Unix text editor used via the terminal. Vim in specific actually has a rather nice GUI called gVim. It's what I used when I used vi-style editors, which overlaps with the last time I used Windows seriously. So, yeah, gVim works on Windows and has for well over a decade now.
- pjmlp 12y ago
  Almost any sane programmer editor/IDE allows for remote editing.
  - xorcist 12y ago
    That's not comparable, when the file you want to edit is only writable by root and you have to go through a jumphost to get there.
    - pjmlp 12y ago
      Ok, that is actually case where text editors are better.
- vertex-four 12y ago
  > When you are SSH'ed into your server and you need to adjust a configuration file This is pretty much exactly what you're not supposed to do in any form of modern system administration. How would you rebuild that server, or move it to a different provider? Edit a local definition of your server for Ansible or Salt or Puppet or whatever else, and let those systems deal with making the server match your definition.
  - Alupis 12y ago
    this heavily depends on the scale of the server of course. not everyone has clusters. your VPS that hosts your blog is an example of something where Salt or Puppet would be WAY overkill.
    - vertex-four 12y ago
      > your VPS that hosts your blog is an example of something where Salt or Puppet would be WAY overkill. I've used Salt for this in the past - it's not overkill, and it's good practice. Ansible is even more lightweight. You can set up a blog, an IRC bouncer, and whatever else, in practically no time. Then, when you inevitably mess it up, you can wipe it and have it running again in 10 minutes. (At the moment, I use CoreOS on my server, so my configuration is just a bunch of Dockerfiles and fleetd unit files that I can edit locally.)
ayrx 12y ago
This is coming from someone that used IntelliJ before moving to Sublime Text 3 before moving to vim for Python development. I am by no means a master of vim's varied features but the best productivity gain for me is vim running in the terminal. I use a lot of command line tools (grep still beats most things for search and the git command line tool is still better than any editor plugins), it's just much more convenient for me when it's all in the terminal and I can switch between them seamlessly with keyboard commands especially when using something like tmux.
- netheril96 12y ago
  Much as I like vim, I think IntelliJ is still better than whatever tools one can cobble together for pure Python development.
  - ayrx 12y ago
    I recognize editor preferences is a deeply personal taste but it's been very different for me. :) I used to swear by IntelliJ but after taking a day to configure Sublime Text (and then vim), I very much prefer them.
    - netheril96 12y ago
      Pycharm has automatic formatting, much better autocompletion (it deduces type based on context), continuous PEP8 check, class hierarchy, refactoring support and a terrific debugger. Don't get me wrong. I am not trying to bash your choice. I am merely curious how to achieve the similar in vim, because I have some urges to switch as well.
      - ayrx 12y ago
        Mostly through plugins really. Jedi is really awesome for autocomplete: https://github.com/davidhalter/jedi-vim https://github.com/davidhalter/jedi-vim This plugin really helps in formatting code: https://github.com/hynek/vim-python-pep8-indent https://github.com/hynek/vim-python-pep8-indent There's another plugin that helps with PEP8 linting: https://github.com/nvie/vim-flake8 https://github.com/nvie/vim-flake8 I just use a combination of print statements and pdb for debugging, I don't trust automatic re-factoring for Python though, so I tend to do them manually with regex. What really helps vim beat PyCharm/IntelliJ for me is the fact that I work with a lot of C code as well as Python. IntelliJ's C support sadly isn't quite there yet.
gfodor 12y ago
Once you're good at vim you can edit at the speed of thought. Not really much better way to put it. Watching non-vim users edit text is eternally frustrating.
- sj4nz 12y ago
  Totally have to agree with this. I've tried a lot of other editors, but keep coming back to Vim. Drew Neil's "Practical Vim" really helped me increase my leverage on using it well, and its tag line is of course, "Editing Text at the Speed of Thought." Whenever I find myself repeating something painful, it is almost always solved by searching the resources in the Vim community for solutions.
- coldtea 12y ago
  I'd say it's mostly busywork and the placebo effect of thinking it took less time to type a Vim text-editing command than do it in another editor. And that's for a marginal use case programmers don't fall much into (if you're frequently re-arranging lines or performing the same actions of blocks of text, then you aren't exactly programming).
  - gfodor 12y ago
    I'd believe this if it was coming from a vim programmer, but generally speaking this claim does not come from someone who uses vim so doesn't carry much weight. Are you highly proficient at vim and still believe it is a placebo effect? Even a small improvement in iteration time has a dramatic effect in the way you approach problems. Vim lightens the mental overhead on making text manipulations so that you simply think about what you want to do and your fingers do it.
deleted 12y ago
[deleted]
jqm 12y ago
Flexibility, configurability, work in the terminal, oh... and did I mention snipmate? That's just scratching the surface. I've been using VIM for around 3 years. Most of the day almost every day. And I feel like I'm barely acquainted with what it can do. Still, it is one of the most important and vital work tools and its hard to imagine life without it. I'm pretty sure I would leave any job I wasn't allowed to use it. Admittedly I went through a rough month or two getting started, but I could see right away that the potential gains in productivity were worth the cost and I'm glad I did. Sort of like learning to type which some people refuse to do because hunting and pecking is faster and easier short term. I'm sure you have seen people like this. And some actually type at amazing speeds for two fingers, but it doesn't compare with what they could do if they took the time to retrain themselves. The problem now is that Vim is so ingrained in muscle memory I type splotch all over any other editor and web browser I touch. Hold on a second, I need to arrow back and clean up this comment... bbbbhhh
zefei 12y ago
The stuff listed in this article are the places where Vim was trying to catch up with modern editors, not where Vim excels. Vim is an old editor, for modern features, Vim has been the one that's catching up, and luckily it did. But that has nothing do with why people love Vim. Vim, in pure code editing sense, has two unique advantages that no other editors have or dare to have: modal editing and ubiquity. Modal editing makes code editing absolutely DRY, as users can avoid any repetitive typing/clicking that they wish to avoid. It doesn't necessarily increase your code throughput much as a lot of the time you'll be thinking instead of typing, but it reduces the frustration of editing to almost zero when you do have to type, hence reducing distractions and cognitive load. Once you are familiar with Vim, its commands have close to one-to-one mapping to ANY ways you want to edit code. For example, you want to change the html text two lines above? kkcit. Then come back to the place where you left? g;g;. Re-indent the lines? =ip. They look foreign and unintuitive to non-vim users, but are actually muscle memories for vim users. This is probably why vim users swear by it, but non-users find it hard to love. Ubiquity is something you can only appreciate when you have to. If your work environment is Windows, this probably won't occur to you. But if you have to code in different OSes, or in SSH sessions, or in git commit, or in less/man commands, you'll find vim invaluable. After all, Vim is just a tool, a very good one. But if your work doesn't have the need for it, you won't find it useful.
netheril96 12y ago
It doesn't increase throughput much because most of the time editing/typing is not the bottleneck. Thinking is. But it is frustrating to reach for mouse and click several times for a task that can be easily done quickly with keyboard. In another words, it interrupts the flow.
brandonmenc 12y ago
Former longtime emacs (and previous to that, vi) user here. vi and emacs seem like magic if you're coming from something like SublimeText. Compared to modern IDEs like VisualStudio or IntelliJ products, however - not so much. vi users tout the rapid text editing features, but you can generate and navigate code just as fast with an IDE - out of the box - no configuration incantations or third party packages required. Until very recently (early to mid-2000s), IDEs for open source web frameworks were non-existent, unaffordable, or slow. Once you have a working vi or emacs setup, there's a lot of inertia in place that discourages switching. That explains the continued popularity of vi, imo.
- cbd1984 12y ago
  > Compared to modern IDEs like VisualStudio or IntelliJ products, however - not so much. Those IDEs only work on some languages, and force you into their workflow. Emacs and vi are both more all-encompassing and less restrictive.
  - brandonmenc 12y ago
    That's true. However all the major languages and frameworks are covered by IDEs, and the workflows they enforce are good enough for 99% of developers. Programmers who are working in a fringe language or who need a specific workflow - vi and emacs are great options - but these days it's a disservice to recommend those out of the gate to a new developer.
    - tuhdo 12y ago
      This is just wrong. Eclipse is an IDE to some languages that it supports, but an average editor to everything else. Have you tried editing configuration files, shell scripts or patch files in it. Eclipse or similar things are terrible when you work in multi-language environment. And look at my other answer that has many demos to see many things your IDE has not yet satisfied me.
      - brandonmenc 12y ago
fsloth 12y ago
"I would be very happy if someone could point out to me the elephant that I am not seeing here." The one thing where vim beats hands down any vanilla text editor, such as you have listed, is the speed of text editing facilitated by its mode-based usage paradigm. It's not the number of features, but the pure effortlessness of the frequently used editing actions vim offers. The technical details are detailed in many vim tutorials. The speed comes from the fact that for a large set of common non trivial operations there is a one or two key sequence that establishes the precise edit you wanted. The way to discover these actions needs a bit of self conscious learning: You notice you do something repeatedly (sometimes painfully obviously) and figure out if there is a quick set of operations in vim to do the thing you wanted to do. To get the full power of vim you need to spend enough time with it so the frequent editing actions you want to achieve are automatically decomposed in your backbone to vim operations, at which point you can edit text at the speed of tought. Also, the split window dual or triple document editing combined with fast commands for switching to different places in the documents is really nice. Notepad++ is my second editor of choice as well.
kansface 12y ago
There is no elephant in the room. Vim will not make you more productive, period. Vim unequivocally takes the fewest keystrokes to effect changes, but its certainly not the fastest editor. At Floobits, we sometimes have 3 devs working on the same code at the same time (normally when something goes really wrong). When ggreer is around, he is always the fastest to edit text bar none. He uses ST3 and a trackpad. If someone is using some Intellij (PyCharm, Idea), that person is the fastest and safest at refactoring bar none. It may be true that some magical Vim invocation is the fewest key strokes in any text editor to edit text. In practice real world Vim users probably lose just as much time as they save trying to find the magical incantation. Beyond saving a few keystrokes, consider how wasteful it is to devote months of effort learning a new text editor when editing text is such a small fraction of the time we spend programming. Are programmers ever limited by how quickly we can type? No, we are limited by how quickly we can think! Having said that, NeoVim is a fairly decent choice for a text editor. It is open source, runs in a terminal, is actively developed, and (vim) is installed on nearly every *nix by default.
- swah 12y ago
  Great point - the editors still can't process code as well as compilers. This should be hapenning already.
- StevePerkins 12y ago
  (quotes paraphrased for brevity) Vim will not make you more productive. At [gratuitous company plug!], the dude with Sublime is the best touch-typist, and the guy with an IDE is good at refactoring. These are false comparisons, and have absolutely nothing to do with Vim. Does your Sublime guy code fast because he's an amazing touch-typist, or because he has better command over Sublime's shortcuts and special features than your Vim guys do? If it's the former, then it's irrelevant. If it's the latter, then it clashes with the point you tried to make in the next paragraph. Of course your IDE guy is better at refactoring code. (S)he's using an IDE. That's what they do, better than any text editor. Comparing editors to full-blown IDE's is fairly "meta" to the topic at hand. However, it should be noted that almost every major IDE has built-on or plugin support for popular editor keybindings. I use Vim keybindings with IntelliJ... and even with my fairly baseline Vim familiarity, I'm able work several times more fluidly than on vanilla IntelliJ. It may be true Vim requires the fewest key strokes to edit text. In practice, you'll lose more time finding those ideal keystrokes. It's wasted effort to learn a text editor, because programmers are not constrained by typing speed. This is just outright nonsense, and tells me that you personally have never learned to use any text editor well. Sure, I would agree that it's unproductive to scour StackOverflow for a magical one-step incantation for EVERY thing you ever do. However, that is not what being proficient with Vim (or any other text editor) means. It means you organically pick up on things over time, such that you aren't having to think about it when using them. If you pick up Drew Neil's book "Practical Vim", it's structured around 121 "tips". Each one is short, clear, and something that you can pick up and internalize in an hour. After the first 24 or so, you will absolutely be more productive that you would be with "Windows Notepad" bindings in the same situation. It's not about crazy incantations that refactor your entire codebase in one keypress. It's about simple little things, that add up: * I want to add an extra parameter to this method I just wrote. So rather than taking my hand off the keyboard and clicking there with my mouse (or hitting the arrow keys over and over), I just press "f)" to jump to the closing parentheses and start adding text. * I want to replace everything on the current line, starting from my cursor position somewhere in the middle of that line. Rather than moving my hand to the mouse and dragging a selection, or holding <Shift> while hitting the arrow keys over and over, I instead just press "c$" and start adding text. Sure, commands can be a bit arcane, but I learned them organically over a period of time... and these are real-world things that I do many times almost every single day as a coder. I probably only use 10% of Vim's available functionality, and that's enough to make my coding a much more fluid experience than it was before. Until you've experienced it first-hand, it's hard to grasp just HOW DISRUPTIVE it is to your flow and thought process to move your hand from the keyboard to mouse and back! I don't care which editor (or IDE keybindings) you use. Vim, Emacs, Sublime, whatever. But you will absolutely be a more productive programmer if you pick one and dig into it over time. You ARE limited by your typing flow, and just don't realize it. If anyone really believes that isn't the case, then why bother to learn touch-typing? Take your two index fingers and try coding with the "hunt-and-peck" method, and see how it doesn't limit your thought process.
sohooo 12y ago
One famous answer to this is: Your problem with Vim is that you don't grok vi. http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 http://stackoverflow.com/questions/1218390/what-is-your-most...
pjmlp 12y ago
I agree. I used vi, vim and was an Emacs user between 1996 and 2005 when coding on UNIX platforms. But I have came to UNIX from the home computers, so I was already spoiled with Borland IDEs and Amiga editors before my first UNIX experience. Got to experience Smalltalk and Oberon environments as well. Always looked for IDE experiences in UNIX land, and since I moved 100% into JVM/CLR land, I only use Emacs or VIM for editing configuration files or when on systems where my beloved IDEs aren't available. Even for C++, thanks to LLVM work, IDEs can offer much more that vi or emacs do, even with CEDET.
- tuhdo 12y ago
  Your knowledge about Emacs was outdated then. And what make you think that Emacs cannot use Clang and LLVM? Currently, there's already rtags that uses Clang for live analysis: https://github.com/Andersbakken/rtags https://github.com/Andersbakken/rtags. Here are some nice features that Emacs provide: - Powerful automatic indentation: https://raw.githubusercontent.com/Bruce-Connor/aggressive-indent-mode/master/aggressive-indent.gif https://raw.githubusercontent.com/Bruce-Connor/aggressive-in.... It does not only indent the current line, but the whole Semantic context around your cursor. - Live grep: http://tuhdo.github.io/static/live_grep.gif http://tuhdo.github.io/static/live_grep.gif - Access to a list of project with a few key strokes: http://tuhdo.github.io/static/helm-projectile/helm-projectile-switch-project.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil... - Quickly access any file in your project, as large as Linux kernel, instantly, regardless of where you are in the project, and within a few keystrokes: http://tuhdo.github.io/static/helm-projectile/helm-projectile-find-files-1.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil.... - Jump to any file depends on context, even if the file path is in a plain ASCII text file: http://tuhdo.github.io/static/helm-projectile/helm-projectile-find-files-dwim-1.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil... - Copy files from anywhere to anywhere: http://tuhdo.github.io/static/helm-projectile/helm-projectile-find-file-copy.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil.... - Delete files anywhere; files are always at your finger tip to do whatever with them: http://tuhdo.github.io/static/helm-projectile/helm-projectile-find-file-delete.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil.... - Switch between other files with same names but different extensions: http://tuhdo.github.io/static/helm-projectile/helm-projectile-find-other-file.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil.... Work not only for C/C++ but other languages, and is customizable. You don't have to configure anything, like adding include paths for the command to search. Everything is automatic. Just use it as it is. - Jump to tag definition, from Emacs's own parser or external parser like GNU Global: http://tuhdo.github.io/static/c-ide/helm-gtags-jump-dwim.gif http://tuhdo.github.io/static/c-ide/helm-gtags-jump-dwim.gif - Jump to any definition from a list of definitions in source tree, even for Linux kernel: http://tuhdo.github.io/static/c-ide/helm-gtags-select.gif http://tuhdo.github.io/static/c-ide/helm-gtags-select.gif - Jump up to parent: http://tuhdo.github.io/static/c-ide/senator-go-to-up-reference.gif http://tuhdo.github.io/static/c-ide/senator-go-to-up-referen.... - Do you like outline tree?: http://tuhdo.github.io/static/c-ide/sr-speedbar.gif http://tuhdo.github.io/static/c-ide/sr-speedbar.gif - Interactive outline tree: http://tuhdo.github.io/static/c-ide/helm-semantic-or-imenu-with-struct.gif http://tuhdo.github.io/static/c-ide/helm-semantic-or-imenu-w... - Easily move back and forth using the interactive outline tree: http://tuhdo.github.io/static/part3/helm-semantic-or-imenu-2.gif http://tuhdo.github.io/static/part3/helm-semantic-or-imenu-2... - References retrieved from its Emacs internal parser: http://tuhdo.github.io/static/c-ide/semantic-symref.gif http://tuhdo.github.io/static/c-ide/semantic-symref.gif. - Beautiful compile output: http://tuhdo.github.io/static/c-ide/compilation-compile.gif http://tuhdo.github.io/static/c-ide/compilation-compile.gif - Frontend support for GDB: http://tuhdo.github.io/static/c-ide/gdb-many-windows.gif http://tuhdo.github.io/static/c-ide/gdb-many-windows.gif - Code completion: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif. - Open man page for symbol at cursor: http://tuhdo.github.io/static/part3/helm-man-woman.gif http://tuhdo.github.io/static/part3/helm-man-woman.gif. - Emacs open 39MB C file: http://tuhdo.github.io/static/performance.gif http://tuhdo.github.io/static/performance.gif - Emac opens multi-gigabtye file: http://www.emacswiki.org/VLF http://www.emacswiki.org/VLF - Emacs is a bit torrent client: https://bitbucket.org/ukaszg/aria2-mode/ https://bitbucket.org/ukaszg/aria2-mode/ You can see more demos in: + Emacs Mini Manual: http://tuhdo.github.io/emacs-tutor.html http://tuhdo.github.io/emacs-tutor.html + C/C++ Development Environment for Emacs: http://tuhdo.github.io/c-ide.html http://tuhdo.github.io/c-ide.html + A Package in a league of its own: Helm: http://tuhdo.github.io/helm-intro.html http://tuhdo.github.io/helm-intro.html + Exploring large projects with Projectile and Helm Projectile: http://tuhdo.github.io/helm-projectile.html http://tuhdo.github.io/helm-projectile.html Note that in the demos you may see me type in the commands. You can think of it like the start menu in Windows, but actually those commands can be executed quickly with a shortcut. I type in the commands for demonstration purpose to Emacs users. Those demos are just tip of the iceberg.
hedning 12y ago
It's not about speed. It's about finding the vocabulary of vim natural (which it seems you don't, which is fine). 'di(' for instance deletes the inside of parentheses. Which is a natural action to perform, if your cursor is inside parentheses.
JelteF 12y ago
The key feature in vim for me is that I never have to move my fingers from the typing position on the keyboard. I never have to look away to find the home key or the arrow keys. All the things mentioned in the article are just there to not miss the nice features of other editors.
super_mario 12y ago
The hippopotamus in the room you are missing is vi. http://www.viemu.com/a-why-vi-vim.html http://www.viemu.com/a-why-vi-vim.html http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 http://stackoverflow.com/questions/1218390/what-is-your-most... The elephant you are missing is UNIX itself. The best IDE ever made.
johnchristopher 12y ago
I absolutely hate having to lift one of my hand off the keyboard to grab the mouse. Vim's text navigation is the top killer feature that all modern editor are lagging behind. The second one is modal mode (editing and navigating/command). I am trying to warm up to ST and the vim plugin is okay but some things are really missing (capital R)
lucb1e 12y ago
> The only advantage I can see in Vim over a modern solution is that it runs in the terminal (which I guess is useful if you like to remotely modify files in your production environment?). ssh -X host Then remotely run whatever tool you want, including Sublime or Geany or Kate or even Wireshark if you wish. > I must say I've only spent ~2 months of my life using vim before giving up, which I think is already pretty long for an evaluation. Hmm yeah that is pretty long, you should see the advantage of it by then. Have you used it a lot in those two months? Because I've alternated between Geany and vim for like 6 months before being fluent enough in vim that I could get work done at the speed I could in Geany (or Notepad++ for that matter). But if I had seriously used vim for everything that I used Geany for, I think I would have easily gotten there in 2 months. > I would be very happy if someone could point out to me the elephant that I am not seeing here. Beyond that it's simply faster in text editing (code, plain text, or something like Markdown for that matter), I guess it's also a way of using a computer. I've never liked the mouse for anything besides games or GIMP and even navigate many websites by keyboard in Firefox. Ideally I'd spend all my time in a terminal, typing away with my hands almost never leaving the home row. But that's just me, I know noone else who is so fond of their keyboard vs. a mouse or touchpad.

Alupis 12y ago

> I personally use Notepad++ Vim is a Linux/Unix text editor used via the terminal. Notepad++ is for the Windows GUI environment. Apples and Oranges. Why is a good terminal text editor important? When you are SSH'ed into your server and you need to adjust a configuration file, you require a good terminal text editor. It also is very good for C programming, and a lot of C programmers use it extensively. There are many other reasons. From a Windows GUI environment, you won't really be able to compare or relate, or understand why vim is so good.

cageface 12y ago
I know Vim well enough to use it for this kind of thing but, IMO, if you find yourself doing a lot of hot edits on live servers you're doing it wrong. Almost all of the editing I do is in a consistent environment on my development machine and I don't see the point of using a lowest-common-denominator tool when I don't have to. I'm sure with some work you can bend Vim into something approaching the power of an IDE but why would you bother? Text editing is a pretty small part of the work of development, after all.
- wyclif 12y ago
  Text editing is certainly a small part of development, but if you're in a dev role where your job involves writing a lot of code, you actually are spending a lot of time in editing mode. I spend quite a lot of time in Vim now because I'm doing a lot of programming, and that's why it's worth spending the time to both learn Vim and configure it to taste. Most of the time what I need to get the job done is a great text editor, and Vim scratches that itch. If, for instance, I was doing massive code refactoring instead I can see why an IDE would be the right tool to use.
pmoriarty 12y ago
Actually, vim is a cross-platform editor. You can use it on Linux, MacOS, and Windows (among many other operating systems). vi is even more ubiquitous. Even if one doesn't use vim as one's primary editor, it would behoove one to learn the basics of vi, as it's available on virtually every operating system.
cbd1984 12y ago
> Vim is a Linux/Unix text editor used via the terminal. Vim in specific actually has a rather nice GUI called gVim. It's what I used when I used vi-style editors, which overlaps with the last time I used Windows seriously. So, yeah, gVim works on Windows and has for well over a decade now.
pjmlp 12y ago
Almost any sane programmer editor/IDE allows for remote editing.
- xorcist 12y ago
  That's not comparable, when the file you want to edit is only writable by root and you have to go through a jumphost to get there.
  - pjmlp 12y ago
    Ok, that is actually case where text editors are better.
vertex-four 12y ago
> When you are SSH'ed into your server and you need to adjust a configuration file This is pretty much exactly what you're not supposed to do in any form of modern system administration. How would you rebuild that server, or move it to a different provider? Edit a local definition of your server for Ansible or Salt or Puppet or whatever else, and let those systems deal with making the server match your definition.
- Alupis 12y ago
  this heavily depends on the scale of the server of course. not everyone has clusters. your VPS that hosts your blog is an example of something where Salt or Puppet would be WAY overkill.
  - vertex-four 12y ago
    > your VPS that hosts your blog is an example of something where Salt or Puppet would be WAY overkill. I've used Salt for this in the past - it's not overkill, and it's good practice. Ansible is even more lightweight. You can set up a blog, an IRC bouncer, and whatever else, in practically no time. Then, when you inevitably mess it up, you can wipe it and have it running again in 10 minutes. (At the moment, I use CoreOS on my server, so my configuration is just a bunch of Dockerfiles and fleetd unit files that I can edit locally.)

ayrx 12y ago

This is coming from someone that used IntelliJ before moving to Sublime Text 3 before moving to vim for Python development. I am by no means a master of vim's varied features but the best productivity gain for me is vim running in the terminal. I use a lot of command line tools (grep still beats most things for search and the git command line tool is still better than any editor plugins), it's just much more convenient for me when it's all in the terminal and I can switch between them seamlessly with keyboard commands especially when using something like tmux.

netheril96 12y ago
Much as I like vim, I think IntelliJ is still better than whatever tools one can cobble together for pure Python development.
- ayrx 12y ago
  I recognize editor preferences is a deeply personal taste but it's been very different for me. :) I used to swear by IntelliJ but after taking a day to configure Sublime Text (and then vim), I very much prefer them.
  - netheril96 12y ago
    Pycharm has automatic formatting, much better autocompletion (it deduces type based on context), continuous PEP8 check, class hierarchy, refactoring support and a terrific debugger. Don't get me wrong. I am not trying to bash your choice. I am merely curious how to achieve the similar in vim, because I have some urges to switch as well.
    - ayrx 12y ago
      Mostly through plugins really. Jedi is really awesome for autocomplete: https://github.com/davidhalter/jedi-vim https://github.com/davidhalter/jedi-vim This plugin really helps in formatting code: https://github.com/hynek/vim-python-pep8-indent https://github.com/hynek/vim-python-pep8-indent There's another plugin that helps with PEP8 linting: https://github.com/nvie/vim-flake8 https://github.com/nvie/vim-flake8 I just use a combination of print statements and pdb for debugging, I don't trust automatic re-factoring for Python though, so I tend to do them manually with regex. What really helps vim beat PyCharm/IntelliJ for me is the fact that I work with a lot of C code as well as Python. IntelliJ's C support sadly isn't quite there yet.

gfodor 12y ago

Once you're good at vim you can edit at the speed of thought. Not really much better way to put it. Watching non-vim users edit text is eternally frustrating.

sj4nz 12y ago
Totally have to agree with this. I've tried a lot of other editors, but keep coming back to Vim. Drew Neil's "Practical Vim" really helped me increase my leverage on using it well, and its tag line is of course, "Editing Text at the Speed of Thought." Whenever I find myself repeating something painful, it is almost always solved by searching the resources in the Vim community for solutions.
coldtea 12y ago
I'd say it's mostly busywork and the placebo effect of thinking it took less time to type a Vim text-editing command than do it in another editor. And that's for a marginal use case programmers don't fall much into (if you're frequently re-arranging lines or performing the same actions of blocks of text, then you aren't exactly programming).
- gfodor 12y ago
  I'd believe this if it was coming from a vim programmer, but generally speaking this claim does not come from someone who uses vim so doesn't carry much weight. Are you highly proficient at vim and still believe it is a placebo effect? Even a small improvement in iteration time has a dramatic effect in the way you approach problems. Vim lightens the mental overhead on making text manipulations so that you simply think about what you want to do and your fingers do it.

deleted 12y ago

[deleted]

jqm 12y ago

Flexibility, configurability, work in the terminal, oh... and did I mention snipmate? That's just scratching the surface. I've been using VIM for around 3 years. Most of the day almost every day. And I feel like I'm barely acquainted with what it can do. Still, it is one of the most important and vital work tools and its hard to imagine life without it. I'm pretty sure I would leave any job I wasn't allowed to use it. Admittedly I went through a rough month or two getting started, but I could see right away that the potential gains in productivity were worth the cost and I'm glad I did. Sort of like learning to type which some people refuse to do because hunting and pecking is faster and easier short term. I'm sure you have seen people like this. And some actually type at amazing speeds for two fingers, but it doesn't compare with what they could do if they took the time to retrain themselves. The problem now is that Vim is so ingrained in muscle memory I type splotch all over any other editor and web browser I touch. Hold on a second, I need to arrow back and clean up this comment... bbbbhhh

zefei 12y ago

The stuff listed in this article are the places where Vim was trying to catch up with modern editors, not where Vim excels. Vim is an old editor, for modern features, Vim has been the one that's catching up, and luckily it did. But that has nothing do with why people love Vim. Vim, in pure code editing sense, has two unique advantages that no other editors have or dare to have: modal editing and ubiquity. Modal editing makes code editing absolutely DRY, as users can avoid any repetitive typing/clicking that they wish to avoid. It doesn't necessarily increase your code throughput much as a lot of the time you'll be thinking instead of typing, but it reduces the frustration of editing to almost zero when you do have to type, hence reducing distractions and cognitive load. Once you are familiar with Vim, its commands have close to one-to-one mapping to ANY ways you want to edit code. For example, you want to change the html text two lines above? kkcit. Then come back to the place where you left? g;g;. Re-indent the lines? =ip. They look foreign and unintuitive to non-vim users, but are actually muscle memories for vim users. This is probably why vim users swear by it, but non-users find it hard to love. Ubiquity is something you can only appreciate when you have to. If your work environment is Windows, this probably won't occur to you. But if you have to code in different OSes, or in SSH sessions, or in git commit, or in less/man commands, you'll find vim invaluable. After all, Vim is just a tool, a very good one. But if your work doesn't have the need for it, you won't find it useful.

netheril96 12y ago

It doesn't increase throughput much because most of the time editing/typing is not the bottleneck. Thinking is. But it is frustrating to reach for mouse and click several times for a task that can be easily done quickly with keyboard. In another words, it interrupts the flow.

brandonmenc 12y ago

Former longtime emacs (and previous to that, vi) user here. vi and emacs seem like magic if you're coming from something like SublimeText. Compared to modern IDEs like VisualStudio or IntelliJ products, however - not so much. vi users tout the rapid text editing features, but you can generate and navigate code just as fast with an IDE - out of the box - no configuration incantations or third party packages required. Until very recently (early to mid-2000s), IDEs for open source web frameworks were non-existent, unaffordable, or slow. Once you have a working vi or emacs setup, there's a lot of inertia in place that discourages switching. That explains the continued popularity of vi, imo.

cbd1984 12y ago
> Compared to modern IDEs like VisualStudio or IntelliJ products, however - not so much. Those IDEs only work on some languages, and force you into their workflow. Emacs and vi are both more all-encompassing and less restrictive.
- brandonmenc 12y ago
  That's true. However all the major languages and frameworks are covered by IDEs, and the workflows they enforce are good enough for 99% of developers. Programmers who are working in a fringe language or who need a specific workflow - vi and emacs are great options - but these days it's a disservice to recommend those out of the gate to a new developer.
  - tuhdo 12y ago
    This is just wrong. Eclipse is an IDE to some languages that it supports, but an average editor to everything else. Have you tried editing configuration files, shell scripts or patch files in it. Eclipse or similar things are terrible when you work in multi-language environment. And look at my other answer that has many demos to see many things your IDE has not yet satisfied me.
    - brandonmenc 12y ago

fsloth 12y ago

"I would be very happy if someone could point out to me the elephant that I am not seeing here." The one thing where vim beats hands down any vanilla text editor, such as you have listed, is the speed of text editing facilitated by its mode-based usage paradigm. It's not the number of features, but the pure effortlessness of the frequently used editing actions vim offers. The technical details are detailed in many vim tutorials. The speed comes from the fact that for a large set of common non trivial operations there is a one or two key sequence that establishes the precise edit you wanted. The way to discover these actions needs a bit of self conscious learning: You notice you do something repeatedly (sometimes painfully obviously) and figure out if there is a quick set of operations in vim to do the thing you wanted to do. To get the full power of vim you need to spend enough time with it so the frequent editing actions you want to achieve are automatically decomposed in your backbone to vim operations, at which point you can edit text at the speed of tought. Also, the split window dual or triple document editing combined with fast commands for switching to different places in the documents is really nice. Notepad++ is my second editor of choice as well.

kansface 12y ago

There is no elephant in the room. Vim will not make you more productive, period. Vim unequivocally takes the fewest keystrokes to effect changes, but its certainly not the fastest editor. At Floobits, we sometimes have 3 devs working on the same code at the same time (normally when something goes really wrong). When ggreer is around, he is always the fastest to edit text bar none. He uses ST3 and a trackpad. If someone is using some Intellij (PyCharm, Idea), that person is the fastest and safest at refactoring bar none. It may be true that some magical Vim invocation is the fewest key strokes in any text editor to edit text. In practice real world Vim users probably lose just as much time as they save trying to find the magical incantation. Beyond saving a few keystrokes, consider how wasteful it is to devote months of effort learning a new text editor when editing text is such a small fraction of the time we spend programming. Are programmers ever limited by how quickly we can type? No, we are limited by how quickly we can think! Having said that, NeoVim is a fairly decent choice for a text editor. It is open source, runs in a terminal, is actively developed, and (vim) is installed on nearly every *nix by default.

swah 12y ago
Great point - the editors still can't process code as well as compilers. This should be hapenning already.
StevePerkins 12y ago
(quotes paraphrased for brevity) Vim will not make you more productive. At [gratuitous company plug!], the dude with Sublime is the best touch-typist, and the guy with an IDE is good at refactoring. These are false comparisons, and have absolutely nothing to do with Vim. Does your Sublime guy code fast because he's an amazing touch-typist, or because he has better command over Sublime's shortcuts and special features than your Vim guys do? If it's the former, then it's irrelevant. If it's the latter, then it clashes with the point you tried to make in the next paragraph. Of course your IDE guy is better at refactoring code. (S)he's using an IDE. That's what they do, better than any text editor. Comparing editors to full-blown IDE's is fairly "meta" to the topic at hand. However, it should be noted that almost every major IDE has built-on or plugin support for popular editor keybindings. I use Vim keybindings with IntelliJ... and even with my fairly baseline Vim familiarity, I'm able work several times more fluidly than on vanilla IntelliJ. It may be true Vim requires the fewest key strokes to edit text. In practice, you'll lose more time finding those ideal keystrokes. It's wasted effort to learn a text editor, because programmers are not constrained by typing speed. This is just outright nonsense, and tells me that you personally have never learned to use any text editor well. Sure, I would agree that it's unproductive to scour StackOverflow for a magical one-step incantation for EVERY thing you ever do. However, that is not what being proficient with Vim (or any other text editor) means. It means you organically pick up on things over time, such that you aren't having to think about it when using them. If you pick up Drew Neil's book "Practical Vim", it's structured around 121 "tips". Each one is short, clear, and something that you can pick up and internalize in an hour. After the first 24 or so, you will absolutely be more productive that you would be with "Windows Notepad" bindings in the same situation. It's not about crazy incantations that refactor your entire codebase in one keypress. It's about simple little things, that add up: * I want to add an extra parameter to this method I just wrote. So rather than taking my hand off the keyboard and clicking there with my mouse (or hitting the arrow keys over and over), I just press "f)" to jump to the closing parentheses and start adding text. * I want to replace everything on the current line, starting from my cursor position somewhere in the middle of that line. Rather than moving my hand to the mouse and dragging a selection, or holding <Shift> while hitting the arrow keys over and over, I instead just press "c$" and start adding text. Sure, commands can be a bit arcane, but I learned them organically over a period of time... and these are real-world things that I do many times almost every single day as a coder. I probably only use 10% of Vim's available functionality, and that's enough to make my coding a much more fluid experience than it was before. Until you've experienced it first-hand, it's hard to grasp just HOW DISRUPTIVE it is to your flow and thought process to move your hand from the keyboard to mouse and back! I don't care which editor (or IDE keybindings) you use. Vim, Emacs, Sublime, whatever. But you will absolutely be a more productive programmer if you pick one and dig into it over time. You ARE limited by your typing flow, and just don't realize it. If anyone really believes that isn't the case, then why bother to learn touch-typing? Take your two index fingers and try coding with the "hunt-and-peck" method, and see how it doesn't limit your thought process.

sohooo 12y ago

One famous answer to this is: Your problem with Vim is that you don't grok vi. http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 http://stackoverflow.com/questions/1218390/what-is-your-most...

pjmlp 12y ago

I agree. I used vi, vim and was an Emacs user between 1996 and 2005 when coding on UNIX platforms. But I have came to UNIX from the home computers, so I was already spoiled with Borland IDEs and Amiga editors before my first UNIX experience. Got to experience Smalltalk and Oberon environments as well. Always looked for IDE experiences in UNIX land, and since I moved 100% into JVM/CLR land, I only use Emacs or VIM for editing configuration files or when on systems where my beloved IDEs aren't available. Even for C++, thanks to LLVM work, IDEs can offer much more that vi or emacs do, even with CEDET.

tuhdo 12y ago
Your knowledge about Emacs was outdated then. And what make you think that Emacs cannot use Clang and LLVM? Currently, there's already rtags that uses Clang for live analysis: https://github.com/Andersbakken/rtags https://github.com/Andersbakken/rtags. Here are some nice features that Emacs provide: - Powerful automatic indentation: https://raw.githubusercontent.com/Bruce-Connor/aggressive-indent-mode/master/aggressive-indent.gif https://raw.githubusercontent.com/Bruce-Connor/aggressive-in.... It does not only indent the current line, but the whole Semantic context around your cursor. - Live grep: http://tuhdo.github.io/static/live_grep.gif http://tuhdo.github.io/static/live_grep.gif - Access to a list of project with a few key strokes: http://tuhdo.github.io/static/helm-projectile/helm-projectile-switch-project.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil... - Quickly access any file in your project, as large as Linux kernel, instantly, regardless of where you are in the project, and within a few keystrokes: http://tuhdo.github.io/static/helm-projectile/helm-projectile-find-files-1.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil.... - Jump to any file depends on context, even if the file path is in a plain ASCII text file: http://tuhdo.github.io/static/helm-projectile/helm-projectile-find-files-dwim-1.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil... - Copy files from anywhere to anywhere: http://tuhdo.github.io/static/helm-projectile/helm-projectile-find-file-copy.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil.... - Delete files anywhere; files are always at your finger tip to do whatever with them: http://tuhdo.github.io/static/helm-projectile/helm-projectile-find-file-delete.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil.... - Switch between other files with same names but different extensions: http://tuhdo.github.io/static/helm-projectile/helm-projectile-find-other-file.gif http://tuhdo.github.io/static/helm-projectile/helm-projectil.... Work not only for C/C++ but other languages, and is customizable. You don't have to configure anything, like adding include paths for the command to search. Everything is automatic. Just use it as it is. - Jump to tag definition, from Emacs's own parser or external parser like GNU Global: http://tuhdo.github.io/static/c-ide/helm-gtags-jump-dwim.gif http://tuhdo.github.io/static/c-ide/helm-gtags-jump-dwim.gif - Jump to any definition from a list of definitions in source tree, even for Linux kernel: http://tuhdo.github.io/static/c-ide/helm-gtags-select.gif http://tuhdo.github.io/static/c-ide/helm-gtags-select.gif - Jump up to parent: http://tuhdo.github.io/static/c-ide/senator-go-to-up-reference.gif http://tuhdo.github.io/static/c-ide/senator-go-to-up-referen.... - Do you like outline tree?: http://tuhdo.github.io/static/c-ide/sr-speedbar.gif http://tuhdo.github.io/static/c-ide/sr-speedbar.gif - Interactive outline tree: http://tuhdo.github.io/static/c-ide/helm-semantic-or-imenu-with-struct.gif http://tuhdo.github.io/static/c-ide/helm-semantic-or-imenu-w... - Easily move back and forth using the interactive outline tree: http://tuhdo.github.io/static/part3/helm-semantic-or-imenu-2.gif http://tuhdo.github.io/static/part3/helm-semantic-or-imenu-2... - References retrieved from its Emacs internal parser: http://tuhdo.github.io/static/c-ide/semantic-symref.gif http://tuhdo.github.io/static/c-ide/semantic-symref.gif. - Beautiful compile output: http://tuhdo.github.io/static/c-ide/compilation-compile.gif http://tuhdo.github.io/static/c-ide/compilation-compile.gif - Frontend support for GDB: http://tuhdo.github.io/static/c-ide/gdb-many-windows.gif http://tuhdo.github.io/static/c-ide/gdb-many-windows.gif - Code completion: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif. - Open man page for symbol at cursor: http://tuhdo.github.io/static/part3/helm-man-woman.gif http://tuhdo.github.io/static/part3/helm-man-woman.gif. - Emacs open 39MB C file: http://tuhdo.github.io/static/performance.gif http://tuhdo.github.io/static/performance.gif - Emac opens multi-gigabtye file: http://www.emacswiki.org/VLF http://www.emacswiki.org/VLF - Emacs is a bit torrent client: https://bitbucket.org/ukaszg/aria2-mode/ https://bitbucket.org/ukaszg/aria2-mode/ You can see more demos in: + Emacs Mini Manual: http://tuhdo.github.io/emacs-tutor.html http://tuhdo.github.io/emacs-tutor.html + C/C++ Development Environment for Emacs: http://tuhdo.github.io/c-ide.html http://tuhdo.github.io/c-ide.html + A Package in a league of its own: Helm: http://tuhdo.github.io/helm-intro.html http://tuhdo.github.io/helm-intro.html + Exploring large projects with Projectile and Helm Projectile: http://tuhdo.github.io/helm-projectile.html http://tuhdo.github.io/helm-projectile.html Note that in the demos you may see me type in the commands. You can think of it like the start menu in Windows, but actually those commands can be executed quickly with a shortcut. I type in the commands for demonstration purpose to Emacs users. Those demos are just tip of the iceberg.

hedning 12y ago

It's not about speed. It's about finding the vocabulary of vim natural (which it seems you don't, which is fine). 'di(' for instance deletes the inside of parentheses. Which is a natural action to perform, if your cursor is inside parentheses.

JelteF 12y ago

The key feature in vim for me is that I never have to move my fingers from the typing position on the keyboard. I never have to look away to find the home key or the arrow keys. All the things mentioned in the article are just there to not miss the nice features of other editors.

super_mario 12y ago

The hippopotamus in the room you are missing is vi. http://www.viemu.com/a-why-vi-vim.html http://www.viemu.com/a-why-vi-vim.html http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 http://stackoverflow.com/questions/1218390/what-is-your-most... The elephant you are missing is UNIX itself. The best IDE ever made.

johnchristopher 12y ago

I absolutely hate having to lift one of my hand off the keyboard to grab the mouse. Vim's text navigation is the top killer feature that all modern editor are lagging behind. The second one is modal mode (editing and navigating/command). I am trying to warm up to ST and the vim plugin is okay but some things are really missing (capital R)

lucb1e 12y ago

> The only advantage I can see in Vim over a modern solution is that it runs in the terminal (which I guess is useful if you like to remotely modify files in your production environment?). ssh -X host Then remotely run whatever tool you want, including Sublime or Geany or Kate or even Wireshark if you wish. > I must say I've only spent ~2 months of my life using vim before giving up, which I think is already pretty long for an evaluation. Hmm yeah that is pretty long, you should see the advantage of it by then. Have you used it a lot in those two months? Because I've alternated between Geany and vim for like 6 months before being fluent enough in vim that I could get work done at the speed I could in Geany (or Notepad++ for that matter). But if I had seriously used vim for everything that I used Geany for, I think I would have easily gotten there in 2 months. > I would be very happy if someone could point out to me the elephant that I am not seeing here. Beyond that it's simply faster in text editing (code, plain text, or something like Markdown for that matter), I guess it's also a way of using a computer. I've never liked the mouse for anything besides games or GIMP and even navigate many websites by keyboard in Firefox. Ideally I'd spend all my time in a terminal, typing away with my hands almost never leaving the home row. But that's just me, I know noone else who is so fond of their keyboard vs. a mouse or touchpad.