[ACCEPTED]-What specific productivity gains do Vim/Emacs provide over GUI text editors?-text-editor

For Vim:

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

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

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

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

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

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

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

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

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

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

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

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

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

The biggest gain: not needing 21 to touch the mouse.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

One other small benefit was that, IIRC, the 6 original vi was designed to speed up editing 5 files over a terribly slow remote connection. Granted 4 that doesn't happen nearly as much today, but 3 if you do have a slow connection, good luck 2 running a gui text editor and having it 1 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.

0

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

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

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

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

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

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

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

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

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

For productivity 1 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 38 having an insert and command mode. While 37 it may seem a throwback to a time when you 36 could not depend on cursor or special keys 35 what it really means is that many powerful 34 motion and text maniuplation commands are 33 a minimal number of keystrokes. Productive 32 coding is not about bulk text entry (the 31 default in "modern" editors) but a burst 30 of bulk text followed by considerable small 29 tweaks and even larger periods of browsing.

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

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

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

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

I use Vim quite often. It doesn't replace 4 UltraEdit for me though. Since a lot of positives 3 have been listed, I guess I'll go against 2 the grain, and list some annoyances with 1 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 8 extensibility of the vim editor. If I want 7 something to work with CVS I can take the 6 CVSMenu plugin and add it to my editor to 5 get that functionality.

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

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

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

Second reason 4 is that we could extend our Vims and Emacs 3 to do all the project specific tasks from 2 DB browsing in a special way to highlight 1 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 44 for decades. Their usage is not going to decline, nor 43 are their features going to break/disappear/change 42 a lot, so you can rely on building your 41 whole career toolbox core around mastery 40 of just one editor.

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

REPL-driven development — Both have "SLIME" modes 36 in various forms that integrate whatever 35 type of REPL you're working with. E.g., I've never 34 encountered iterative development as powerful 33 as that provided by CIDER.

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

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

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

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

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

Beyond just editing — Emacs 9 goes farthest here with the ability to read 8 news, browse the web, manage email, edit 7 spreadsheets, create presentations, and 6 organize anything.

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

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

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

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

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

And that blew my mind.

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

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

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

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

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

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

One advantage that all console-based editor 3 has over GUI editors is that they can be 2 run in a terminal multiplexor such as screen or 1 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 66 and as C# user since 2003, from this bias 65 pov it's fair to do this otherwise unfair 64 comparison (Another could be VS C++ with 63 Visual Assist X vs C++ in vim/emacs):

For 62 C# and Visual Studio:

1. I just counted the 61 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 60 about emacs feature for jumping in the code. I 59 don't think it has feature exactly like 58 that. It has a similar feature though. Here's 57 the downside of VS. There's lot of little 56 features but over time they stop working. Last 55 I checked the jump feature didn't work but 54 that was couple years ago. VS introduced 53 a new graphical jump feature that I've been 52 using instead. It requires mouse or touch.

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

The problem with mouse based 47 GUI navigation is that

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

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

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

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

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