Subtitled: Why Emacs is Right for Me
And hopefully for you, too. With the turn of the new year, I witnessed my 20th birthday. I have been programming for a decade! Sounds like a long time when I put it that way- and I figured it was high time to reminisce a little. Here are some of the things I realized.
Computers can be nice additions to our lives. Before utility, though, much of our society ranks computers on other alleles. We’ve all seen people with computers on display to impress, aesthetic appeal surrounding who knows what. We’ve also seen the guy on the bus with 5 year old hardware, glued and fastened in place who knows how to implement dumb terminals and can jive with what others can’t use well enough to produce meaningful action. On the inside, some people decorate their operating systems with widgets and whistles, graphics and shadows and watts because they can. How a computer looks really affects how a person comes at the computer. But why are we assuming any given person knows how this computer works? What happens if this is the first time this fellow has come across a device like this?
I feel every device should be intuitive for the user it was designed for. Sounds like a reasonable statement, right? Sadly, not everybody is capable of pulling that off. I haven’t personally used Windows 8, but I hear for the folks using it without a touch interface, they are really stumped with esoteric key bindings and cryptic interfaces. Everything they were used to was switched around- a common event with graphical managers of any variety- and millions of “power” users were lost adrift. These users could be considered to be ‘first-time users,’ and did the designers of the operating system keep this golden rule in mind? The grumbles and malcontent stirring in the wake of the release of 8 indicate that they did not.
So how can I get into the mindset of the ‘unfamiliar computer user?’
I remember the first time I used my parents computer. I was quite young- 4? This monolith was running Windows ’95, fresh from the printing press. I didn’t know enough to assume I could operate a program, so I fiddled with the remaining visible portion of the screen: the desktop. I right clicked (incidentally on the corner of an icon), because left clicking was boring, and the first item looking unfamiliar was “Set as Desktop Background.” Not knowing any terminology, I had no clue what this could mean. I clicked, not taking into account any potential permanent, un-undoable actions, and was horrified when the entire screen changed color as a new picture assumed the screen. Somebody would know I was there! My heart sank. I can still recall the fear I felt that my parents would think I was intruding on their machine. Machines were personal, attended to, prized companions, right? I instinctively knew I had to revert the picture, and this was the thought path my mind spawned:
Holy smokes! So this picture is the new background- how can I find the old background? I have no clue, it could be in any of these things look like folders! I don’t have time to open them all- can I do sort of reverse image search? Shoot, I don’t know, even if that’s possible I don’t know where to find it. Where can I find help??
I realized just now that to this day, over 15 years later, I think about tasks on the computer in exactly the same way. Figure out some steps that seem plausible, and would solve the problem, and then consult the docs. The superiority of Emacs over other editors is its excellence in each of the above categories of thought- search, help documentation, customization. If I had been able to search for the picture I had in mind, or had been able to revert the change I had made I would have done so with a clear sequence of a subset of the commands provided by Emacs. This breakdown happens to correspond to a well defined algorithm, atomic directives intended for the machine. With Windows as an introduction to computing systems, one might assume a user must manually conduct directives all the time. One also might mistakenly assume that help dialogues don’t get any better than Microsoft’s. Who else says this must be the case? Consider this process.
I take notes in a structured format. I like exporting my notes as (if one takes well enough notes, might one have one’s self a study guide for 10$?) so I usually maintain one monolithic document. To begin each lecture (in each class, 4 times in certain days) I usually create a new block with the text “* Lecture <number of lecture>” and today’s date. When I’m running late, the last thing I want to do is break out the formatting rules before feeling comfortable about transcribing the material I’m missing. In order to compensate for the worst case scenario, and because laziness is the virtue of a true programmer, the process must be automated. In Emacs, this is quite an enjoyable process. The task is simple- and well defined. Does one even need conditionals for this sort of thing? If I consider my above, 4 year old approach, I might end up with a function looking like this
This is a function that algorithmically, step-by-step defines what I want to do at the beginning of each lecture. If today is day 2, I end up with something like
* Lecture 2
..Thursday January 17, 2013
Note: Emacs also provides alternatives to defining a task like this, which can be quite rote. Supposing I want to define a very long task? I would rather take the following approach:
Create a keyboard macro:
Run through the desired action
End the keyboard macro:
Name the keyboard macro:
M-x name-last-kbd-macro demonstration
Insert the macro as Emacs lisp:
M-x insert-kbd-macro demonstration
Emacs will give you a more concise rendition than my elisp:
which accomplishes exactly the same result. This binds the function call “demonstration” to the series of keypresses you see before you. They are not stored commands, but rather instructions to play back while masquerading as the user, to be interpreted at run time. In different modes, with different key bindings, the results may vary- so caveat emptor.
My point is this: Emacs is created around a basis of well documented commands. Reading any Emacs literature will inform you that pressing a letter key, “e” will run
self-insert-command. Every action you might perform, nay think of, is an Emacs command. How does this benefit the user? Well, imagine you are able to build commands like the one above, though this example is even trivial in nature. What if you were able to lump together simple commands in order to achieve larger, more meaningful actions? How would that change your workflow? Emacs users enjoy the convenience of hundreds of key bindings. Devising novel finger combinations is an old hobby of a real Emacs user*. They have the luxury, see, to bind any function to any keypress. This coincides with their ability to coordinate ideas into functions. How awesome is it when complex actions, like the ability to update all the dev machines at work; or the ability to sort regions of text alphabetically; or the ability to process your Perforce checkin logs at the end of each day with a script to write a work report totaling the number of bugs crushed is just one stroke away.
In the above example, one could expertly define the function manually, or, even if certain commands involved in the process were totally foreign to the user, one could simply record the process with the intent of automating it later (with one key-combo, by the way:
C-x e). Can Windows users do that? Why not? It is one of the single biggest time savers of my day! Even not knowing all the magic of Emacs can be very much made up for by some wit with the macros.
This, and much more, is possible with Emacs. Couple that with the best free documentation I’ve ever seen in my entire life, added to the tireless efforts of the wonderful emacs community, multiplied by more modes and packages than one could hope to comprehend, raised to the power of FOSS, is why you should consider using Emacs.
It doesn’t get any more intuitive or fundamental than that. Even a four year old could do it.
* I say this because nobody likes to type out
M-x some-command-name, even with all the comforts of auto-completion and packages like smex. The less frequented commands can instead be bound to less frequented (custom, obscure) key bindings.