notmyfirslanguage

Why I Chose Vim

when I write Vim, please read Vim/Neovim

I wanted to learn a tool that I could rely on for years to come. I wasn't a programmer (still ain't), but I intended to become one, and I didn't want to learn lots of different tools in order to be efficient. Vim also had the aura of being the tool of choice of “real” programmers. There was some attached value to knowing it, and it seemed like a good text-editor anyway. I liked using Linux and the command line, and the notion that you could do everything without leaving the keyboard was an attractive idea. It seemed to be the good kind of hard, the one that rewards your efforts with years of dividends.

My Time with Vim

My initial plan was to spend the first three months learning Vim and start my programming journey after that. How naive I was! Seven months later I'm a reasonably advanced Vim user, but I haven't learned any “real” programming besides making my own functions in Vimscript. In the beginning, I thought I would never use another text editor. Vim was flexible enough for my needs. I used a bunch of plugins for Python, notes and other stuff. It was a constant battle to make everything work smoothly. It wasn't easy. Vim excels in terms of speed, but its plugin environment can be hard to navigate. Complex tasks were difficulty to accomplish because the plugins had to work in perfect sync. I'm not saying it was impossible to make it work, but the effort vs reward ratio wasn't good. Things broke all the time. Vim-slime and Python Mode are two examples of great plugins that gave me a lot of trouble. In the case of the last one, I simply gave up and used IDLE instead. I'm not saying these are not good plugins, the real problem is making them work together. On the other hand, I wasn't willing to go full IDE and use something like Pycharm. I loved the flexibility of Vim, but I wanted something complete out-of-the-box. I was also looking for solutions to help me organize my schedule, studies and everything else. Org Mode was the obvious solution, but I wasn't ready to leave Vim just yet.

Trying Vim-orgmode

Vim-orgmode seemed like a good compromise: it had some of the functions of org-mode without the need to learn Emacs. With 1780 stars on Github, it was clearly a popular project. But names can be deceiving. While Org Mode has a large bulk of built-in functionality, its Vim counterpart requires the installation of nine different plugins in order to supplement its features. Some are quite old, like Universal Text Linking, last updated in 2008. Opening an org file with Vim isn't fast, and the outline cycling is not smooth either. Editing files is really sluggish, even for simple operations like typing or deleting a character. I tested it with everything else disabled and the results were the same. Complex operations, like using the agenda, were also delayed.

Vim-orgmode miss some core functionality, too. Sparse-trees is a big one. They give you the ability to create customized outlines, which fold the entire file while leaving visible only the information you selected. Table support is another powerful tool the Vim version haven't implemented yet. It's a great way to organize information: Org “magically” takes take care of the formatting, making it easy to export your tables to pretty much all markup languages you can think of. In my experience, org-md-export-to-markdow works particularly well.

Vimiwiki is a better plugin in this category, with a more focused scope. It makes no direct attempt to reproduce Org Mode.

After exploring these options, I realized that I needed Org Mode in my life. I'm about to start a new phase, both professionally and academically, and my old fragmented habits won't cut it anymore. Like Robert De Niro in Taxi Driver, I thought,

Emacs: first impressions

But before I could be productive with org-mode, I had to decipher a beast called Emacs. I thought it would be a good idea to start from scratch. My first approach to Vim was not structured: I understood how the settings worked by copying and pasting and messing with code. Emacs wouldn't reveal itself that easily. For better or worse, Elisp is not as simple as Vimscript, at least for the kind of tasks I use it for, like remapping commands and adapting simple functions.

Remapping was my first shock. While in Vim I was able to do that from the get-go, Emacs required a deeper understanding. As an example, the following binds “Control+c i” to the subsequent commands in Vim:

nnoremap <c-c>i mZ:buffer scratch<cr>iHello<space>World<esc>`Z

1. sets current position globally to the marker “Z”
2. goes to a buffer called “scratch”
3. inserts “Hello World” in said buffer
4. goes back to position Z

Here's some Elisp that does the same thing (from Mastering Emacs):

(defun switch-to-scratch-and-insert-text ()
  (interactive)
  (save-excursion
    (set-buffer "*scratch*")
    (insert "Hello, World")))
(global-set-key (kbd "C-c i") 'switch-to-scratch-and-insert-text)

While the second example seems better structured, the first is, in my opinion, more adequate as nothing more than a configuration tool for writing small pieces of code that you only use once.

I think Emacs's verbosity enforces better practices, though. It makes more sense to stop and think on how to make your bindings more local if you're writing a function already. The equivalent for Vim would be using filetype plugins. I prefer the Emacs way in that regard.

A Fist Attempt

My first attempt at Emacs was a failure that left me utterly confused. Configuring stuff in a foreign language was an ordeal, so I used the customize command instead. I didn't know if that was a good idea (it wasn't), but at least I got things done. The problem with using this tool is that you learn little about your installation, which makes it hard to debug or customize it beyond what the tool allows. But I got the hang of it, little by little. I went through some sections of the Introduction to Programming in Emacs Lisp, and I really liked it. But there was still a lot of stuff I couldn't figure out, so I got impatient and installed Spacemacs, which is kind of great, but not what I was looking for. I wanted a nice platform for customization, not a highly opinionated distribution. Customizability is one of the main reasons why I chose Emacs in the first place. I don't want to create an entire layer just to make my keybindings make sense. Furthermore, it makes no sense for me to become a specialist in Spacemacs. I wanna learn tools that are distribution agnostic and help me “communicate” with Emacs in a more direct way.

On Evil and the Evil-collection

Evil-mode and Evil-collection are among the best packages in the emacsphere, and do a great job making Vim users feel at home, but not every mode is remapped. You'll have to customize many things to your liking, and a brief knowledge of Emacs keybindings is beneficial. Evil users live in little islands surrounded by Emacs. So don't fool yourself thinking you'll be able to simply translate what you already know. Emacs is a powerful Lisp machine that will change the way you think.

A Second Attempt: use-package

Use-package is an awesome tool that translates the Emacs packaging into something I can actually understand. Your bindings and configurations go nicely along with the package declaration.

Here's an example of how to install evil-mode with it.

(use-package evil
  :ensure t
  :init
  (setq evil-want-integration nil)
  :config
  (evil-mode 1))

The use-package bit is always there. ensure t means “install if not already installed”. :init is for settings you want to be loaded before the package, and :config is for the settings that only makes sense after it's loaded. It can be tricky sometimes. In order to install the packages, you can either restart Emacs or run M-x eval-buffer on the file. When in doubt, refer to use-package's great documentation.

general.el

general is not strictly necessary, but it makes it easier to create and manage keybindings. It has a focus on evil-mode, but can be used without it. Right now all my keybindings use the general.el syntax, separated from the use-package declarations. It's possible to use general within use-package, but the advantages of doing so are unclear to me and I'd like to avoid this extra level of complexity for the time being.

Here are some evil mappings I made using it. These only work in the normal state. Notice how it's possible to bind a set of keys to another, just like Vim does.

(general-define-key
 :states '(normal)
 "Y" "yg_"
 "gr" "vg_"
 "gp" "vg_h"
 "ge" "vg^"
 "gç" "gwap"
 "M-j" "mzddp`zj"
 "C-ç" 'avy-resume
 "M-k" "mzddkP`z2k"
 [?\t] 'evil-toggle-fold
 "c" 'evil-destroy-change
 "ç" 'avy-goto-word-0-below
 "zi" 'vimish-fold-toggle-all
 [escape] 'save-buffer)

Back to Org Mode

Org Mode is a challenge in itself because you need to learn the tool at the same time you create workflows to use it with. It's not that hard after you decide which features you're gonna use. There are lots of questions to answer in the meantime.

• When to use properties instead of tags?
• Why should I use the agenda instead of multiple headings?
• Should I write in org-mode markup, or just link markdown files to my index?
• Should I use a single large file or lots of smaller ones?
• Should I have lots of capture templates, or use helm/ivy to find the right note?

Whatever decisions you make, Org Mode is probably the best tool for the job. I, for example, have a lot of trouble focusing on my tasks, so I put everything in a single document. Inside my index.org I have every information related to my classes, readings, assignments, and deadlines. Everything is neatly arranged using lists and headlines. I usually write in the same file, using org-narrow-to-subtree to visualize the current topic as a separate document. And even though I'm writing this post using markdown-mode, there's a link to it on my index so I don't lose context.

Capture templates are just a fancy way to tell org-mode where to put something you type. The template bellow says:

1. find the file at the location ~/index.org
2. inside this file, find the headline This Week
3. insert the third string, performing the % expansions according to the org-mode syntax

(setq org-capture-templates
("w" "This Week" entry (file+headline "~/index.org" "This Week") "* TODO %<[%a, %d/%m]> %i%?"))

I use ivy to access my capture templates with the command counsel-org-capture.

The syntax itself is not that complicated but can scare people without previous exposure to code. I have a bunch of capture templates. It's not that hard after the first one. I did a course on Regular Expressions a while back, and I think it helped me understand this kind of syntax. Regex is a fascinating subject, it's a shame some people hate its guts.

A Note on Emacs Window Management

Emacs windows have the terrible habit of messing up with user's layouts. You never know where they're going to pop pup. There are several modes dedicated to improve this:

• eyebrowse
• purpose
• popwin
• shackle
• ace-window

I was able to achieve a reasonable configuration combining evil commands, eyebrowse, and ace-jump. But I still find Emacs window management too unpredictable for my taste, so I frequently use it as a daemon. That way I can generate as many frames as I want, and manage those with the same keys I use for all my other i3 containers. It works well most of the time, but when I restart Emacs all the instances go down.

Conclusion

After some adaptation, Emacs is a very nice editor. The interpreter is powerful, and Elisp is a capable language. It is more verbose than Vimscript, and simple tasks require a daunting degree of Elisp knowledge. Because of that, I'm not sure if I'd be using Emacs right now if not for general and use-package.

On the other hand, Emacs modes usually have more features and fewer bugs than their Vim counterparts. But I don't think this pseudo-rivalry between Vim and Emacs even makes sense anymore. They belong to different categories. Vim is an excellent text editor that you can expand up to a limit. It should be compared with Sublime, Atom and kakoune. Emacs is a Lisp machine that can be extended to a much larger degree. There's even an Emacs window manager! It should be compared with Pycharm, Eclipse and Visual Studio. Comparing Vim and Emacs, as if they belong to the same category, is as useful as comparing a Toyota Corolla with an 18 wheeler. They're different tools with different use cases. I still use both, and I'm happy with this choice.