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

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.

Answer 2

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.