What specific productivity gains do Vim/Emacs provide over GUI text editors?

This isn't meant as a troll or flamebait or anything like that. I've been using Vim as my console-editor of choice for a couple months now (for editing configuration files while in my terminal), but I don't think I could stand it for my normal, every day work of writing web applications, which I do with a GUI text editor (which one isn't important).

I feel like my GUI text editor can do everything I need for my work. It has a decent search/replace with auto-complete histories for both. It has syntax highlighting, line numbering, a tabbed interface, easy copying and pasting, etc. The only thing my current editor is missing is regular expression matching, but there are plenty of GUI text editors that will do regex search/replace.

Given what I just said, what productivity advantages does Vim (or even Emacs) have over a GUI text editor aside from that fact that it is installed on every computer. I'd like specific tasks that are better/faster on Vim/Emacs or that are just not possible with existing GUI text editors.

For Vim:

• Vim has better integration with other tools (shell commands, scripts, compilers, version control systems, ctags, etc.) than most editors. Even something simple like :.!, to pipe a command's output into a buffer, is something you won't find in most GUI editors.

• A tabbed interface is not as nice as the "windowed" interface that Vim/Emacs give you. You can see two or more files at the same time side-by-side. The more you can see on-screen, the more you free your mind to think about your problem rather than doing mental bookkeeping of variable names and function signatures.

• Don't underestimate the power of Vim regular expressions. There are a lot of Vim-specific extensions to match a specific column, a mark, the cursor position, certain classes of characters (keywords, identifiers) etc.

• Integrated diff and grep (platform independent so you don't need to download and learn a new tool every time you change computers).

• Visual block mode (to edit columns) is something many editors lack, but that I can't live without. I have shocked and awed people at work using just this, making some edit in a few keypresses that someone would've otherwise spent ten minutes doing manually.

• Multiple copy/paste registers. When you only have one, you end up going through strange contortions to avoid clobbering the clipboard. You shouldn't have to.

• Vim's undo/redo system is unbeatable. Type something, undo, type something else, and you can still get back the first thing you typed because Vim uses an undo tree rather than a stack. In almost every other program, the history of the first thing you typed is lost in this circumstance.

• Moving around, copying, pasting, and deleting text is insanely fast in Vim. The commands are simple, single keypresses, and composable. Add up all the times you do a careful, laborious mouse highlight and Ctrl-X, then replace them all with a da( (delete a set of matching parens and everything in them). It saves more time than you'd think

• The little things, like * to search for the word under the cursor, or . to repeat a command, or % to bounce between an opening and closing paren. Way too many of these to list.

• Built-in scripting language and powerful key-mapping and macro ability so the editor can be extended in whatever ways you need. Tons of scripts already written and downloadable.

If you look closely enough, you'll find that even features that other editors also have, Vim often does better. All editors have syntax highlighting, but Vim has a syntax file for nearly every file format under the sun, often with lots of configuration options, and it's dirt-simple to write your own. Lots of editors handle different file encodings OK, but Vim gives you very specific and foolproof ways of setting file encodings and converting between them. The very first thing that impressed me about Vim is how perfectly it handles tab/space indentation options and Unix/DOS linebreaks compared to other editors that I had problems with at the time.

Many of these points apply equally well to Emacs (in different but usually equally-powerful ways).

(vim's my poison; I'm sure emacs offers similar gains)

The biggest gain: not needing to touch the mouse.

For me, the handiest thing is to jump forward to (or just before) a specific letter or combination of letters, or jump back, with a couple of keystrokes. Jumping forward by the same condition twice, or ten times, is simply a matter of prefixing it with a number.

If you've to repeat an edit, you jump forward to that place (2-3 keystrokes), then hit "." to repeat the last edit. Jumping forward (or backward) is easier - one keystroke - if it's the same search condition.

Basically, with a small lead-time, you can learn ten or twenty keyboard shortcuts that mean you don't have to keep shifting your hand to grab the mouse. That gives you three or four times as many editing movements/commands as you'd do if you had to keep grabbing the mouse.

After a few days, you'll find yourself getting grumpy every time you have to reach for the mouse (or hit <Down> 15 times), when you're in a GUI editor.

I always wondered why few people were gaga over Vim. See the video of Vim power user in action:

https://www.youtube.com/watch?v=FcpQ7koECgk

If your current editor can do what he is doing, there is no need to switch! :)

Also, read this http://www.viemu.com/a-why-vi-vim.html

After watching the video and reading that article, I had no choice but to start learning VIM. It's been almost a year since I switched to VIM and I can't imagine using anything else.

I think one of the real powers of a dedicated text editor is macro editing. Repetition is painful for a lot of programmers, and writing proper macros can be borderline entertaining. If you're not doing everything through the keyboard, creating macros will require an extra set of commands rather than making use of the ones you already are using.

I'm semi-competent with vi keybindings, but I prefer Emacs overall. The reason these editors have such fervent adherents is because the editing model they provide is more powerful than newer systems, which is why providing "vi keybindings" or "emacs keybindings" isn't enough, even if you aren't using any extension features or customizations for emacs or vi.

I'm only going to talk about Emacs' model because I understand it best. The common model for text editing today involves a buffer of text, in which text can be inserted, deleted, selected, and cut/copied/pasted to the system clipboard.

Emacs buffers, of course, can support these operations. Along with tracking cursor position for each window they're visible in, they also keep track of "marks" made in them. The text between the "point" (cursor position) and the "mark" is called the "region", and roughly corresponds to the selection in mainstream editors.

The difference is that Emacs keeps track of the last several locations the mark was set at in the mark ring, and you can return to them with a keystroke (or two, depending on your configuration). I find this extremely useful, especially since a lot of Emacs commands that change your location in the buffer set the mark at your old location. An example is when I'm editing a Python module and need to add an import statement to the top of the file. The keystroke for going to the top of the buffer (Alt-<) sets the mark. I add the import statement. I press Ctrl-u Ctrl-Space and I'm back where i started. I can keep doing this to cycle back to previous positions as well. (Maybe I needed to select some text while adding that import statement.)

The other (and more well-known) Emacs difference is the kill ring. Most of the keystrokes for removing text from the buffer save text to the kill ring, which can then be recalled with the "yank" command (Ctrl-y). The essential feature is that subsequent yank commands retrieve older killed text. So you can kill several sections of text in a row, then retrieve them in order. You can also cycle through the kill ring with Alt-y after a yank, removing the retrieved text and inserting the next entry in the ring.

Emacs had these features in 1978. The only other major system to adopt them to any extent is NeXTStep (and now inherited by Cocoa). Other tools provide more features for specific tasks, can be extended in languages way easier to use than Emacs Lisp, and have nicer visual interfaces... but Emacs remains better at text editing. Which is why, once you know how to use it, it's so hard to quit.

This is not exactly a specific task, but for people who even might be suffering from RSI, the fact that your hands never leave the keyboard in vim is almost priceless. I actually ended up going lefty on my mouse at work because it let me move my hand less to reach for the mouse (my keyboard at home doesn't have a number pad, so I can keep it on the right).

One other small benefit was that, IIRC, the original vi was designed to speed up editing files over a terribly slow remote connection. Granted that doesn't happen nearly as much today, but if you do have a slow connection, good luck running a gui text editor and having it be responsive.

For me the big productivity things are

• I can do pretty much everything from the keyboard.
• Powerful macros.
• In my 20 year carreer using 9 OSes the basic keyboard bindings haven't changed. I can hop on pretty much any system and already know my way around the editor.
• Pretty much any feature you might ever want in a text editor has already been added.

One thing that I really like about vim is the "repeater" command. Basically, by pressing . in command mode, it repeats your last action. This is just one example of really cool features that "programmer text editors" have that often GUIs don't.

In my experience, the main productivity gains which vim and emacs (I'm a vim person myself, but emacs is surely similiar) provide are:

• You can have those features which modern IDEs provide (like one-keypress edit-build-run cycles and inline documentation and tab completion and whatnot) but you don't have to. The productivity gain? You see only as much as you want to see. In my experience, IDEs didn't make people more productive, also because they showed too much information (all kinds of browsers). This "extra bit of power, when you need it - but no sooner" is quite a productivity gain IMHO.

• The editors are very popular among programmers, which means that there are huge repositories of scripts, books and usergroups available.

• In my experience (I can only speak for vim here) the average vim user is a fairly good software engineer. I don't know why that is (or maybe I'm just lucky), but maybe people who took the barrier of getting accustomed to an 'old' tool like emacs or vim have the right dedication (and contact to other people like that). Maybe it's an indirect effect of these editors, but hanging out with other vim (or emacs) people on e.g. IRC turned out to be quite interesting, since the same people were also quite interested in all kinds of software engineering (or computer science) issues. These editors seem to attract a certain kind of personality. :-)

The "productivity gain" I get for using a lightweight emacs clone for tiny programs is that it starts up like greased lightning. I can usually bang out a quick test program in C# before Visual Studio would have finished loading a "sandbox" solution.

Of course, I could just leave Visual Studio open (or another VS open if I'm working in it at the time) but then it would get swapped out if I left it idle for a while, etc.

For anything of any significant size - or if I don't know the API I'm using pretty well - an IDE is the way forward, IMO.

I use gvim for windows, so technically it's a GUI text editor, but it is vim..

For productivity enhancements, I find:

1. I never have to use the mouse, therefore I'm faster.
2. search, replace, copy/paste etc are all faster with vim keybindings vs mouse movements (once the learning curve was surmounted)
3. As mentioned in the previous comments, RSI's are reduced significantly. My wrists have thanked me since I moved to vim.
4. it's lightweight and fast

You know, for vi I think it comes down to having an insert and command mode. While it may seem a throwback to a time when you could not depend on cursor or special keys what it really means is that many powerful motion and text maniuplation commands are a minimal number of keystrokes. Productive coding is not about bulk text entry (the default in "modern" editors) but a burst of bulk text followed by considerable small tweaks and even larger periods of browsing.

This came to the fore for me personally using vi over a high latency campus network. You could easily get 10 or 15 characters ahead of the response. With vi I could comfortably predict where those commands would leave me and be able to work at near normal speeds. This twisted expertise is a continued benefit under normal conditions -- less visual brainpower dedicated to constant graphical feed back.

The commonplace * and # word search accelerators are great for flipping through code. And % for matching parenthesis is extremely useful. Sure, hardly seems like much compared to ctl-] but half the keystrokes adds up.

Personally, I use winvi which adds a couple big things that I'm sure vim has as well. A quick jump into hex mode cracks a lot of "what the hell is going on" text problems. And the completely flexible handling of line endings is a godsend that has become an expected feature for a text editor. Finally, it can open any file no matter what the contents. This amounts to an elite hacking skill of the first order.

Under Unix you can quickly capture program output or even filter sections of your file through external commands. An extremely powerful yet I think underutilized function.

I use Vim quite often. It doesn't replace UltraEdit for me though. Since a lot of positives have been listed, I guess I'll go against the grain, and list some annoyances with Vim.

• Weak FTP handling. I "sort" a lot of sites, and not being able to easily browse and edit files on a remote FTP server is a big deficiency for me. NWRead is not good enough.

• Console weirdness inherited from the general terminal issues that seems to plague Linux. I usually use PuTTY to connect to my Linux box (running Ubuntu), and for some reason, the arrow-keys maps to A/B/C/D in insert mode (and the whole color support issues). In gVim, ctrl-tab can be mapped to "bn" easy, but not in console mode, such issues abound.

• The search/replace options are very weak, interface wise. Having to type the whole thing into a single line, is just not good enough. I feel the much more elaborate dialogue in say UltraEdit gives me much more power in the end, even if the actual regular expression support may be much weaker.

• Too strong a reliance on US keyboard layouts. A lot of keys that are used for primary functions, such as `, are non-printing on my Danish keyboard-layout (and located arkwardly, same with $, and many others). Makes it quite awkward to use some functions.

I'd say one of the big advantages is the extensibility of the vim editor. If I want something to work with CVS I can take the CVSMenu plugin and add it to my editor to get that functionality.

Same with syntax highlighting, behaviour with specific files, etc. All sorts of things can be tailored in vim.

Not so sure if you can do that as easily in GUI type editors.

Remote Desktop shows quickly only native Windows application. We've tried to use Eclipse to develop under unix. And you know what? It wasn't even possible.

Second reason is that we could extend our Vims and Emacs to do all the project specific tasks from DB browsing in a special way to highlight and auto complete our owns meta language.

(My background is a few years with Visual Studio and other IDEs, then 15 years of Vim, and the most recent 6 months with Emacs.)

Longevity — Vim/Emacs are FOSS, and have have been around for decades. Their usage is not going to decline, nor are their features going to break/disappear/change a lot, so you can rely on building your whole career toolbox core around mastery of just one editor.

Remote/ubiquitous access in terminals — Although both have fine systems for editing remote files, you can also have them installed on any system you ever log into.

REPL-driven development — Both have "SLIME" modes in various forms that integrate whatever type of REPL you're working with. E.g., I've never encountered iterative development as powerful as that provided by CIDER (but hear that Emacs with Common Lisp goes even further).

Linting — Whatever language you're using probably has some linting tools, whether built into the compiler or an external tool. These integrate seamlessly with Emacs/Vim, showing your coding slip-ups in near real-time.

Grammar of mnemonic commands — Although both take some time to learn, these editors feature famously clever systems for accessing — and even remembering — thousands of commands with a few keystrokes and key combos. These can fully eliminate any need for using a mouse if you're so inclined.

Built-in help systems — The offline documentation of many languages and their APIs is common to find built into these editors, and is accessible in similarly simple ways to the vast and comprehensive help systems they feature. Auto-completion has been added for most common languages. Additionally, there is a wealth of discussion help on virtually any help topic.

Navigation — tags, paredit-likes, marks, windowing, tabs, vim-rails' jumping, and many more built-ins.

Package managers/repositories — Emacs has a few (elpa, melpa, marmalade) and Vim's are good, too (vundle, pathogen, etc). I don't know of any communities around IDEs that offer anything comparable to these. I see more than 5,000 packages with Emacs' package-list-packages.

Beyond just editing — Emacs goes farthest here with the ability to read news, browse the web, manage email, edit spreadsheets, create presentations, DB/Git/etc clients, and organize anything.

Integrated everything else — debuggers, browser syncing, compiling, shells, test running.

Infinitely customizable — Elisp is a very powerful language for extending/modifying Emacs. VimL is Vim's equivalent. There are books written on both. Tweak color themes and behaviors to your delight!

Language Agnostic — Many GUI editors are tailored for a single language. Emacs/Vim are/can be suited for any language (now or future). Much of what you tune your workflow to for one language can be carried over to others. This also means your text editor serves as your document editor; nothing separate for Markdown, Org, HTML, TeX, etc.

Tunable — Wanna slim down the enabled features to be able to handle a million line file? Run on a monitor that displays 400 lines? You can turn off all sorts of things off to make it work.

Mouseless — Some folks find that avoiding the mouse can really speed up a workflow. Both fully support (and arguably encourage) never touching the mouse.

Record and Replay in VIM is unbeatably awesome, which you are very unlikely to find in GUI based tools.

Also auto increment/decrement gives it data generation capabilities without writing programs for it.

I'd been a desultory Emacs user for years. But never really got into it. Then I started learning Clojure (my first Lisp) and discovered ParEdit.

And that blew my mind.

(See here for some examples : https://www.youtube.com/watch?v=D6h5dFyyUX0 )

Lisp + ParEdit is the most amazing editing experience I've ever had. Nothing else comes close. Lisp is no longer an awkward language to write, forcing me to worry about balancing lots of irritating silly parentheses. With ParEdit, the consistent Lisp structure becomes a huge bonus to work with, as the same tree-transformations - slurping, barfing, splitting and joining - work everywhere, in control structures and data-structures alike. And ParEdit prevents me from making stupid mistakes. It becomes almost impossible to make syntax errors.

And unlike Eclipse, this isn't some laborious real-time checking that's always running in the background, burning up my processor. It costs nothing ... ParEdit simply does the correct structural change when I ask for it.

(In general Emacs is as fast as it needs to be. Unlike Eclipse which is like typing in glue.)

The next thing I discovered was Yasnippet ( http://emacswiki.org/emacs/Yasnippet ). Once again, I'd not used anything like this before. Not simply a macro to add boilerplate, but a dynamic, navigable form.

The final pleasure is the realization that if I want to extend this thing myself, to have more of these high-level productivity tools, I have the power of Lisp itself to work with.

One advantage that all console-based editor has over GUI editors is that they can be run in a terminal multiplexor such as screen or tmux. Why is this good?

• It is faster to switch from one terminal multiplexor console to another than it is to switch from one GUI console to another using the mouse, or even using alt-tab. This is because consoles can be named, and switched to by typing a few characters of the name.
• If your editor sessions are in a terminal multiplexor's consoles, you can access them from any machine. If I need to do some work from home, I can ssh into my box, attach the already running terminal multiplexor to my ssh session, and be right where I left off when I left work.

As vim/emacs are often used by programmers and as C# user since 2003, from this bias pov it's fair to do this otherwise unfair comparison (Another could be VS C++ with Visual Assist X vs C++ in vim/emacs):

For C# and Visual Studio:

1. I just counted the amount of keystrokes for this line:

        public List<string> Names = new List<string>();
    //  3      3    3      1111111111111            211   =3+3+3+8+5+2+1+1 = 26 keys strokes + 3 uses of Shift while typing the line above in VS C# 2013 vs 47 key strokes for non-IntelliSense IDE's
    //                              (IntelliSense offers the List<string> because that's what you're likely after here but you can type something else if you want)
    // https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction explains on how this is impl. for C#. In C++ I've heard of 3rd party VS plugin that improves or replaces the VS C++ auto-complete
   

2. I read about emacs feature for jumping in the code. I don't think it has feature exactly like that. It has a similar feature though. Here's the downside of VS. There's lot of little features but over time they stop working. Last I checked the jump feature didn't work but that was couple years ago. VS introduced a new graphical jump feature that I've been using instead. It requires mouse or touch.

3. Here's where emacs/vi win. If you have to jump around a lot in the code, VS features for this either don't exist or haven't been tested enough.

The problem with mouse based GUI navigation is that

a) just like sitting in very static position maybe bad, if so, mouses tend to make your fingers be in static position also. My wrist pain went away with change to trackball. I first tried vertical mouse but it didn't do anything for the problem.

b) My ideal keyboard would have 2 rows of function keys, no numpad, so I could place trackball closer, makes the jump distance more bearable.

Ultimately however, if you want to jump between few specific places, it's clear the "mark ring" is more effective. VS has something along those lines ... last I used it, it just didn't work reliably...

c) and there's likely a ton of small features that break with each release so this is the downside of VS.

Solution to this "closed source" problem: Write the entire VS in C# and then allow modding/editing the compiled code (at runtime, saving changes as patch that gets optionally loaded on next start) without releasing the source. This can be done by having the decompiler output the code as it was when going in. 180 degrees from how native compilers work. The binary then becomes the source code and the executable instead this mess of .cs files and .exe files etc. There exists 3rd party tools that can almost do this already, so "modding" C# exe's is rather trivial but I propose taking this to the logical conclusion: include even comments in the .exe and .dll. The files are still going to be tiny compared to compiled C/C++ apps. Optimization? You could also include pre-optimized code. When the modder mods the exe while the app is running, the non-modded "AST" and the accompanying optimized binary is plugged back in. Same idea as in the C# compiler but taken further. Next step: Write entire OS in this language, so that even when Windows is closed source, it can be trivially modded as the source code comes with every binary. No setting up environments, compiling, linking. Just modify the OS while it is running. Close analogy: If you wrote web browser in Common Lisp, you could edit the web browser without stopping it and build web pages in the same language as the browser.