Impressions of Emacs and Org Mode

Posted on August 7, 2015 by Richard Goulter
Tags: , ,

I’m a moderately capable Vim user.
I’ve not quite gained the habit of trying to constantly improve using Vim; but at the same time, I’m not exactly using it as something only slightly better than Notepad++.

Lately I’ve been taking quick glances at Emacs.
I was impressed by this post from GitHub user bling, who suggests that Vim is the better editor, with a much larger/better plugin-writing community; but suggests that Emacs makes for a better Development Environment.
– Org mode makes sense as a ‘gateway drug’ to Emacs..

Org Mode

The testimonials you see of Org Mode compel interest. In terms of a comprehensive note-taking/task-managing format, I’m not aware of any other formats/doctrines which are anywhere near as popular.

There are a couple of ‘implementations’ of a subset of Org mode’s features, for vim: jceb/vim-orgmode, and hsitz/VimOrganizer.
The latter is somewhat less popular, and doesn’t include even a token README, and hasn’t had updates in a year. – It may still be alright, but I’ve not tried it.
The former has had commits within the last couple of months, does have a README, and is more popular.

vim-orgmode is mostly alright.
From when I’ve tried to make use of it, there’re a few annoyances I’ve had:

It wasn’t a problem for me, with this vim-orgmode plugin, that not every (applicable) part of Org mode was implemented. Org mode seems to have an extensive feature set, and I can’t (at this stage) see myself using most of the features.
What was kindof interesting is that many of the Org mode things were implemented in Python as a library.

– While perhaps using Org mode as a poor-man’s-OneNote may not be making the most out of Org mode, I’ve also found it unclear as to the distinction in purpose between headers and unordered lists: I often find myself with an unordered list of things, and then will want to ‘TODO’ these.

Emacs

So, as it is, Emacs is the tool to use to manipulate Org mode.
Evil mode certainly mitigates the pain of this.

Emacs feels like it’s an editor in between worlds:
Emacs, in some sense, rightly has that “programmer’s editor of choice” feel to it: it can be customised with macros, it can be run in a terminal, a prominent irc channel, etc.; in these ways, it’s very similar to Vim.
But, it also feels like it’s a ‘modern’ editor. It’s start-up time is slow. The text isn’t regular-width, regular-height; you can embed images in the editor. Installing plugins, customising features of the editor can be done through a (somewhat shabby) UI within the editor, which includes rendered buttons, textfields and other widgets.
– Particularly jarring, for example, when writing in Org mode, the formatting of the text is shown as you edit. If text should be bold, then in Emacs the text is bold. Like how MS Word does it; but different than I’m used to when writing markup.
Yet, Emacs just doesn’t feel as ‘polished’ as these.

– I ran into a problem: my Org mode looked bad. The tags were being aligned making use of tags. Org mode assumed a tab width of 8 (which somewhat defeats the point of one of the key advantages to tabs, but okay). The tab width was set to 8, but being rendered as 4-wide.
– The culprit? The solarized mode I was using. I looked at the code; there’s no mention of tab anywhere!
But also interesting (or horrifying) to note in the solarized.el file (about 2k LoC) features many lines of code dedicated to setting the colour for each face, for a multitude of different modes. It seems to me if you want to write a mode which looks good with this theme, then the theme would have to know about your mode, and be customized to that. – I’m thinking this is an example of a downside of Emacs’ flexibility. Or perhaps colour schemes are just hard to do properly, and this kind of upstream coupling is the best way.


Newer post Older post