I am an avid Emacs enthusiast in a company full of Vim users. In fact so many people I work with like to use Vim that they even created a company wide Vim config for everyone to use. This has presented a problem to me: Emacs or Vim? On the one hand, I absolutely love Emacs and have invested significant time into customizing it to work exactly the way I want. But on the other hand, I want to be on board with the tools everyone I work with is using.
Is the solution here to just accept the fact that Vim is an excellent text editor too, and adopt it for my work? No way!
The Evil Solution
Instead, I decided to just to port Atomic’s Vim config into Emacs and use both editors at the same time. Fortunately for me, someone has already done most of the work for me by creating Evil, the Extensible vi layer for Emacs.
Evil provides a basic modal editing environment within Emacs, and ports most Vim commands over as well. The best part is that with a few simple configurations, you can make it so that the equivalent to Vim’s insert-mode is just normal Emacs with all the associated goodness.
Since Evil had already done most of the work of porting Vim into Emacs, most of what I had to do was copy some keybindings from Atomic’s shared .vimrc and map them to equivalent Emacs functions. This task was actually relatively painless, since most of the ported functionality already exists in Emacs under different names or can be obtained via an add-on package. For example, Emacs doesn’t really have anything like NERDTree built in, but emacs-nav serves as a pretty good replacement.
Emacs or Vim?
Now that I’ve been using this setup for a couple weeks, I’ve gained an appreciation for both editors and the things they do and don’t do well.
Advantages of Vim
I much prefer working with blocks of text Vim-style. If I want to copy 7 lines of text,
is much more elegant than:
C-a C-SPC C-u 6 C-n C-e M-w
I also prefer Vim’s find and replace semantics and a few other things.
The best part is that I now feel comfortable enough with Vim commands that I can pair program on someone else’s machine using Vim without difficulty.
Advantages of Emacs
However Emacs has its wins as well. The most frustrating thing for me about regular Vim is not being able to move around a line as easily when I’m in insert mode. With Evil I can have
M-b without jumping in and out of insert. There are also some add-ons for Emacs that I have grown really attached to and integrated into my workflow such as Magit and flymake. Emacs also has its traditional wins over Vim of being more all-encompassing feature wise and being far more extensible with its Emacs Lisp interface. But the advantages of Emacs go deeper than that.
Getting Both with Evil
As far as I’m concerned, Evil means I have no reason to ever use real Vim again. The traditional editor war argument of “Vim or Emacs?” can essentially be summed up as:
- Vim is a better text editor.
- Emacs is a better everything else.
Evil is the missing link here that brings Emacs up to speed in the one critical area that many felt it often lagged. With evil you have what is essentially a full Vim environment wrapped into a more powerful and more easily extensible interface, and you don’t have to sacrifice your user experience to get it.
My Emacs config is a continually evolving creature and it lives on Github along with some documentation. While I have not yet completely ported over Atomic’s Vim configuration, most of the important pieces are there along with many of my own enhancements.
Improve software development by passing along shared knowledge and best practices.
One of the biggest challenges in application development today is how to factor in application-specific information. The answer lies in the ability to capture application evolution and developers' knowledge of building and extending the application as metadata so that it's not lost in time or translation. Once that can be done effectively, the combination of the application code along with application-specific metadata can be meaningfully packaged into reusable software asset modules. This white paper will discuss how 'Application Factories' can transform an IDE to play a central role in capturing both the application evolution and the developers' knowledge.