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

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

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 2

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.

Answer 3

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

Answer 4

G'day,

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.

HTH

cheers,

Answer 5

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 6

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

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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

Answer 11

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.

Answer 12

I always wondered why few people were gaga over Vim. See these videos of VIM power user in action:

[WARNING: Windows Media Player video]

http://blog.eleutian.com/download/vimteaser.wmv

http://blog.eleutian.com/download/vim2.wmv

http://blog.eleutian.com/download/vim3.wmv

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 13

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.

Answer 14

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. :-)

Answer 15

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.