From Emacs to Vim – Chapter #1 – Vim plug-ins

This is the continuation of the first post.

As you get the feeling and overview of vim, the first thing you’ll probably miss [as an probable-soon-to-be-emacs-orphan (actually, not really, I’ve already told you I’m not going to abandon emacs – for example, this post is being written within it, with org2blog – (too many level of parenthesis, please help me!!))] are your customizations and custom plug-ins and extensions.

A couple of google searches would bring me to projects like janus and vim bootstrap. Those look nice and I would probably appreciate them if I were a beginner. However, as a super user – if you read this statement as bragging, then you are probably not understanding the purpose of this mini series –, I like to be in control of the personalization and settings of my text editor. Right? So, I’ve chosen to control my own plug-ins. In other words: bottom-up instead of top-down.

Now, the two state-of-the-art plug-in managers you’ll find out there to manage your vimscripts are vundle and pathogen. I began using Vundle, but after a few hours I realized that pathogen was KISS and superior. Period.

Not that Vundle is bad. It looks (works) okay too; in this case it was simply a matter of personal choice. The way Vundle works is as follows: your .vimrc will be populated with several lines such as:

Plugin 'tpope/vim-surround'
Plugin 'username-from-github/repository-name'
Plugin 'matchit'
Plugin 'vimscript-name-from-vim-dot-org'
Plugin 'git://'

Then, you just have to install those plug-ins with a simple command:


Done. It is simple, yes, but I liked more the approach of pathogen: you maintain a git repository with your plug-ins. Each new plug-in is a git submodule within your repository. Yay, this means it is super-easy to set up and share your plug-ins with other people. This is exactly what I’ve done: you can peek out my vim repository here.

Now, there is one super good advantage here over emacs. The cost of adding a new plug-in is practically zero. This has two meanings, actually:

  1. vim start-up time is ridiculously fast. Even with a dozen plug-ins, I still don’t notice it. With emacs, if I don’t run it as a daemon, it is a nightmare: a couple of seconds (yeah, a couple of seconds is really a nightmare, not kidding) of start-up time.
  2. I don’t even have to touch my .vimrc to add a new plug-in. I just have to clone a new repository into my $HOME/.vim/bundle folder. Period. With emacs, I have to continuously poke my .emacs file to add, remove and constantly tweak my extensions. Yeah, I’ve been doing that for a while, and it does provoke a lot of stress and anxiety. You already have to tolerate a little bit of RSI with emacs, so you don’t need more problems.

Now, don’t undermine my (our) dear Emacs! Emacs Lisp will (and will always be) superior to vimscript. I have no doubt of this fact and therefore I won’t even discuss it here. Emacs is much more extensible than vim.

Okay, then what? You have to find a few plug-ins, right? In Emacs, most plug-ins with decent quality you might find will be available either on MELPA or Marmalade and, of course, on GitHub too. In vim, it looks like the home of scripts is the vim website itself ((1) and (2)) and GitHub. I couldn’t find a central repo or website hosting the majority of its plug-ins, as with emacs. However, there is vim-awesome, which indexes existing ones (this concept is like the ruby toolbox, and Emacs paradox extension by Bruce Connor.

I won’t discuss the plug-ins I’m using right now, however here is a snapshot of my $HOME/.vim/bundle directory at the time of this post (19 plug-ins, yay):

- YouCompleteMe
- ack.vim
- ag.vim
- ctrlp.vim
- delimitMate
- nerdtree
- syntastic
- tagbar
- vim-airline
- vim-bufferline
- vim-commentary
- vim-easytags
- vim-fugitive
- vim-gitgutter
- vim-markdown
- vim-misc
- vim-repeat
- vim-sensible
- vim-surround

Most of those have an emacs equivalent. Okay, I’m stopping here for now, until the next post 🙂

Update: next post.

From Emacs to Vim – Chapter #1 – Vim plug-ins

From Emacs to Vim – Chapter #0

Hi there. This will probably become a new mini series. I begin by quoting Vanessa Da Mata:

É só isso
Não tem mais jeito
Acabou, boa sorte
Não tenho o que dizer
São só palavras
E o que eu sinto
Não mudará
Tudo o que quer me dar
É demais
É pesado
Não há paz
Tudo o que quer de mim
That’s it
There’s no way
It’s over, good luck
I’ve nothing left to say
It’s only words
And what l feel
Won’t change
Tudo o que quer me dar / Everything you want to give me
É demais / It’s too much
É pesado / It’s heavy
Não há paz / There’s no peace

Upstream URL with lyrics.

Now, a little bit of context.

Two or three weeks ago I began learning vim. This is due to a lot of reasons: one of them is that vim is actively used by a lot of members of the Arch Linux community, and I usually am influenced about their tastes — what doesn’t mean that I will comply with everything, it is just a matter of trying new things. Another reason is that I am actively learning new open source tools, and vim is definitely one of the most widespread and ubiquitous ones. I don’t need to provide statistical sources for that, do you agree? Vi is present everywhere, even on my Android. (Now, almost nobody uses vi anymore, however vi and vim are too much similar that for simple and rapid tasks usually annoying differences won’t even be noticed). Another reason is that I never became 100% satisfied with Emacs. Hey, I like emacs very much, don’t get me wrong, however there were always some piece of completeness missing in it, so this puzzle never got finished. In particular, orgmode (an emacs task-manager-note-taker-and-everything mode) is a tool that I felt in loved with, and thanks to it I won’t completely remove emacs from my system; you should notice that orgmode is something very specific to emacs. Although there are some tentatives on vim implementations, as far as I read, they are not very good (at least not compared to a vanilla, emacs orgmode).

Okay, those are sufficient for now, but there are more reasons that will reveal themselves along the next posts.

Now, we should go back to the lyrics. I really love how this music is related to emacs; in particular,

Tudo o que quer me dar / Everything you want to give me
É demais / It’s too much
É pesado / It’s heavy
Não há paz / There’s no peace

That’s is right. Emacs always was regarded to as the dinosaur, as the operating system of your computer, as the I-want-to-rule-all-your-workstation program. This has both its advantages and disadvantages, of course. The point with vim is that is tries to Keep it Simple. It will never be everything: it is only your text editor. Nothing more. Well, although people will always try to write a Twitter Client for it and similar things, I feel it is not natural. No, IT IS NOT!! Now, with emacs, those things are pretty natural. It was created to be extended! (Emacs is described as the extensible text editor.) Along the last two years, I’ve tested more than a hundred of add-ons and customizable pieces and bits for it: it is so cool how a functional language (Emacs Lisp) can improve a text editor. 2048 game, flappymacs, twitter client, mediawiki client, xkcd browser, RSS reader, calendar application (built-in), calculator (built-in), mail client  Yeah, emacs is everything! Maybe too much for me.

Now, this is the part that makes me feel a little sad: There’s no peace. Yeah, this is a problem. If you browse through my dotfiles repository on Github, more specifically, through its commit history, you’ll see that my .emacs file is one of the files that most changed through the days. I am always editing something of it, and I am never completely 100% satisfied with the outcome. Because it is to easy to tweak and customize almost every aspect of Emacs, this means it is also possible to customize some aspects that I should probably not even be bothering to (and I should probably not touch those ones). Now, this proved to be a problem through the last months. As a programmer, a text editor cannot (should not) get more attention from me than, say, a project or a series of projects I am working at the time. This is significant because a vanilla emacs is very bad (that is, emacs is only good after you customize it to your needs). While I could argue that there are already third party pre-customized emacs (such as prelude and emacs-starter-kit — for more, see on Xah Lee’s blog), pretty good customizations by the way (do I need to say I’ve tested them all?), this wouldn’t stop me from further customizing my dear dot-emacs file.

Now, during the last days, two emacs tools (one official and another one operated by the community) have made me keep calm and further stop me from customizing my emacs file: they are customize.el and el-get. I wish I could have used and discovered these tools through my early days of emacs (not after two years!). Nowadays I am pretty tired of elisp, so vim will be a form of going away from emacs for a while.

Hey, I’ll stop this post here. But there are so many things I still want to talk about. Let’s create a Org list for this:

** PROGRESS introduction, motivations, and so on
** TODO org2blog
** TODO functional programming, REPL and Emacs Lisp
** TODO keybindings, keystrokes and hotkeys paradise (or nightmare)
** TODO more org-mode goodness
** TODO lessons and overall learned discipline
** TODO about the awesome emacs community
** TODO emacs blogs and RSS out there?
** TODO evil-mode
** TODO Emacs on X vs Emacs on Console
** TODO Books and study sources on Emacs
* TODO Vim
** TODO how a emacs user feels after being introduced to a modal text editor
** TODO keybindings and maps in different modes
** TODO gvim vs vim
** TODO vim community and resources?
** TODO editing text at the speed of thought, really?
** TODO books and study sources on vim
* TODO Conclusions
** TODO Are text editors still relevant today, in a world of full-featured IDEs?

Whoa. I hope you might like this mini series and want to see some  (or all!) of the above topics discussed. During it (please notice this comment won’t be repeated further on), feel free to leave out any comments about your specific experiences about vim or emacs. Also, you are encouraged to suggest me additional topics about my experience with emacs (and my soon-to-be-born experience with vim too), and even choose one of the above topics to I write about next.

Until the next post! (For now, read this.)

Update: next post.

From Emacs to Vim – Chapter #0