What specific productivity gains do Vim/Emacs prov

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

(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.

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 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, 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!

Answer 4

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.

Answer 5

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.

Answer 6

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.