If you haven't read it, do so. It has an interesting outlook on what it means to write code, and asks the question, "why the hell are we stuck in the 60s?" His basic premise is that we're married to ASCII, despite having all sorts of other characters at our disposal via unicode, which provides much clearer and concise possibilities for syntax. He also goes on about how none of us have monochromatic screens, so color could play some role in what our programs mean, as well as arguing that the vertical nature of code is unjustified, since we have column editing.

If you ask me, his other arguments are crap, but the unicode argument is completely valid. There's just one problem, have you ever tried to type unicode? It's a mess. In Emacs, to type →, it's C-x 8 RET RIGHTWARDS ARROW RET, or if you know the hex value, C-x 8 RET 2192 RET. Sure, there are other options, but most editors aren't nearly as flexible to customize as Emacs is, so who knows what it's like outside of it—I can't imagine it's any better.

But, when I commented on the fact that "typing unicode sucks," I was greeted by an email from a friend of mine:

DrRacket lets you enter common Unicode characters by typing their LaTeX name followed by control-\. For example, you type ∈ by typing "\", "i", "n", "control-\". It's easy enough that I use Unicode in my code all the time. I bet it wouldn't be too hard to hack something like this feature into Emacs. —Casey Klein

This got me thinking about the problem, and in 20 minutes I had C-\ bound to a function that would read a TeX symbol name from the minibuffer and looked up the unicode character in a table then spit it out. I then began to go on a typing spree, seeing how easy it actually was to use. Of course, this wasn't exactly what Casey had described, but it was close enough, and made it way better than before.

It actually had some great features of it's own, too. For one, it had TAB completion, to cut down on typing. DrRacket didn't have that.

I told Casey about my efforts and mentioned TAB completion and how "this isn't all that bad." Casey was intrigued by the TAB completion, and I wanted to see if C-\ after typing \in was better—it is, but there's still value some value in the prefixed entry.

So now I had a function bound that would do the right thing. If point was at the end of a word boundary with a \ to the left of it (the word), it'd attempt to convert the sequence to a symbol, otherwise it'd be left alone. If you were in empty space or the completion failed, you'd be asked for the symbol as if you were going the prefix route.

This all worked wonderfully well, and our conversation about why I don't like entering unicode went on; he was still convinced it was woefully easy. I, too, was beginning to see that it's not as painful with the proper tools as I originally thought.

The 43 message thread of back and forth sparked inspiration in him around the idea of completion for DrRacket. His idea was simple, hit C-\ and it'd attempt to complete whatever was before it, or output the longest subsequence of the symbols, prefixed with whatever you typed, in the lookup table. In other words, if you had "\sub" it'd complete to "\subset" because both "\subset" and "\subseteq" are in the lookup table. Hit C-\ again and the substitution to ∈ takes place.

I couldn't help but be inspired to add that behavior to what I had now dubbed unipoint. His changes went into DrRacket. We both found solace in the fact that typing symbols was a bit easier than it was before.

I'm a lot less scared now to see symbols in code, and certainly advocating for them, so long as they stay mathematical in nature. I can't help but feel, though, that most people see this still as a problem. It's because of this that I recorded a quick screencast tutorial (no audio) of how unipoint is used. Hopefully it does its job in showing that it doesn't have to be so painful, and Kamp's dream will eventually become a reality.

Today, I'm even closer to Emacs than I was before, having an extra year and a half of experience than I did then. My daily interactions with Emacs are still very much in the same vain—I am still a programmer after all, but I've also discovered some more frustrations which were fairly easy to rectify.

In July of this year, I started a new job^[1]. My role at Meetup has been different in many regards than my previous jobs. It's the first role I've had since entering into the industry that someone doesn't see the output of my code. In fact, if they do see the output of my code, I've sort of failed.^[2] It also represents the first time that I've primarily used a compiled language (outside of college), targetted the JVM and used Java for the bulk of my work.

Naturally, Emacs could help me. Compilation Mode, for instance allows you to do M-x compile to run make, or ant (with -emacs) or some other build tool that generates compilation mode compatible output, that the mode will then mark up and allow you to easily jump to places the compiler thinks^[3] are errors.

Compilation Mode by default is fine, but complicated Java source trees are normally nested quite complexly and ant isn't the greatest at locating a suitable build file. What I needed were some interactive functions that I could use to run ant properly, in Compilation Mode using the project's build file. What I came up with after a few hours, works fairly well.

Basically, instead of M-x compile, I type M-x ant, or M-x ant-compile, or M-x ant and then TAB complete all the available build targets. This allows me to save some typing, and save some precious brain cells, since I don't have to remember all 40 build targets.

The code is fairly simple, and I think it's a great candidate for a walk through on how to solve your own problems using Emacs Lisp, so I'd like to go through it here.

The code starts out simply enough:

(defvar ant-last-task "compile")
(defvar ant-build-file-name "build.xml")
(defvar ant-command "ant -emacs")
(defvar *ant-tasks-cache* '())
(defvar *ant-tasks-command* "grep -e '<target.*name=\"[^\-][^\"]*.*$'")
(defvar ant-tasks-default '("compile" "test" "clean"))

We just define a bunch of global variables that can be overridden by a user if they need to be. We do however create *ant-tasks-cache* and *ant-tasks-command* which are meant to be internal state. In elisp, and other Lisps, wrapping * around a variable normally indicates that the variable is special in someway, here it means it's a global and shouldn't be modified outside of the functions defined within.

Next we have a helper function, ant-find-tasks, which, given a directory, issues a shell command *ant-tasks-command* that is used to extract the lines from the ant build file that declare targets:

(defun ant-find-tasks (directory)
  (let ((output (shell-command-to-string (concat *ant-tasks-command* " "
                                                 directory "/"
                                                 ant-build-file-name))))
    (if (> (length output) 0)
        (mapcar '(lambda (x) (replace-regexp-in-string ".*<target.*name=\"\\([^\-][^\"]*\\).*" "\\1" x)) 
                (split-string output "[\n]"))
      nil)))

Essentially, we first save the output of the shell command that gets built up to the variable output. If the length of output is greater than 0, we split the output (split-string) into individual lines, and iteratively replace the junk in the line with just the name of the target (replace-regexp-in-string). The only non-obvious thing in here is mapcar which is a fancy way of transforming a list into another list via the function passed as the first argument.

That gives us all the tasks defined in the build file—well for most cases anyway. It doesn't handle all possible, valid build.xml files, but should work if the target's declaration and name attribute appear on the same line.

When we need a list of tasks for a project, we call ant-tasks. This function really just caches the returned value of ant-find-tasks into the global variable *ant-tasks-cache* for the current project:

(defun ant-tasks (directory)
  (let ((tasks (assoc-string directory *ant-tasks-cache*)))
    (or tasks
        (progn 
          (let ((newtasks (or (ant-find-tasks directory) ant-tasks-default)))
            (setq *ant-tasks-cache*
                  (cons (cons directory newtasks) *ant-tasks-cache*))
          newtasks)))))

The only interesting thing about the above code is the use of or. In Lisp, or short circuits and returns the first truthy value—it doesn't convert it to a boolean, so it can easily be used to select the first truthy value from a list of values. That's what's happening there.

I mentioned that I wanted TAB completion on task names so as to not clutter my brain matter with useless task names:

(defun ant-get-task (directory)
  (let ((task (completing-read-multiple (concat "Task (default): ") 
                                        (ant-tasks directory))))
    (if (> (length task) 0)
        (mapconcat 'identity task " ")
      "")))

Well, here it is. Emacs has built in completion via the completing-read function. Here, we want the ability to issue one or more tasks, so we use completing-read-multiple to get the job done. Notice we're calling our function from above, ant-tasks.

You'll notice mapconcat above. It's like mapcar from above, in that it takes a list of things and transforms them, but instead of returning a new list, it concatenates the elements into a string using the last argument (here just a space) as a separator. completing-read-multiple returns to us a list, which we need to turn into a string with spaces between the targets in order to issue the build command.

(defun ant-find-root (indicator)
  (let ((cwd default-directory))
    (while (and (not (file-exists-p (concat cwd indicator)))
                (not (string-equal (expand-file-name cwd) "/")))
      (setq cwd (concat cwd "../")))
    (if (file-exists-p (concat cwd indicator))
        (expand-file-name cwd)
      nil)))

The above function locates the base directory of the project, given the current file being edited. It just loops up the file system looking for the first directory it finds that has a build file in it. When I originally wrote this function, I didn't realize that Emacs already had this functionality built into it with the function locate-dominating-file.^[4]

ant-kill-cache,

(defun ant-kill-cache ()
  (interactive)
  (setq *ant-tasks-cache* '()))

does exactly what it says it does. It destroys the cache that is built up from ant-tasks.

The main entry point, ant, is fairly trivial as well. It sets the variable default-directory, which is Emacs' current working directory, to the project directory, reads a task from the reader (if being called interactively) and calls compile, which is the main entry point into Compilation Mode.

(defun ant (&optional task)
  "Run ant `task` in project root directory."
  (interactive)
  (let ((default-directory (ant-find-root ant-build-file-name)))
    (if default-directory
        (let ((task (or task (ant-get-task default-directory))))
          (setq ant-last-task task)
          (compile (concat ant-command " " task)))
      (message "Couldn't find an ant project."))))

In the first code block, there was a variable, ant-last-task, defined that is used above to store the last target run. After a target is given, it's saved off in there.

(defun ant-last ()
  "Run the last ant task in project"
  (interactive)
  (ant (or ant-last-task "")))

(defun ant-compile ()
  (interactive)
  (ant "compile"))

(defun ant-clean ()
  (interactive)
  (ant "clean"))

(defun ant-test ()
  (interactive)
  (ant "test"))

The rest of the code above, just defines some convenient, interactive commands for common targets. M-x ant-compile will just issue the compile target, likewise for ant-clean. The only moderately interesting interactive command here is ant-last which reuses the variable ant-last-task from above to redo the last compilation.

It doesn't feel like much code, and in all reality it's not. However, it has saved me quite a bit of time, as I don't have to go running to a terminal (either switching buffers, or switching windows entirely) in order to issue an ant task. I just do something I've grown very accustomed to—I issue another Emacs command, and let Emacs take care of it for me.

1. We're hiring for most positions.
2. Most of what I do is related to our product's infrastructure—not interaction, and not engineering new features. My work would be visible if some error leaked to your browser, and that'd probably be bad.
3. It's fairly difficult to trick the compiler, but in Java, for instance, you can write type-safe code using Generics that it can't prove is safe. If you do that though, you should make use the SuppressWarnings annotation to tell the compiler it's OK.
4. Actually, I wasn't surprised that Emacs actually had the functionality, just that the name is non-trivial. I gave up looking for it after a couple of minutes and just rolled my own. I'll replace it in a future version, but the existing code works for now.

I'm not going to sit here and type out a Top 10 list of reasons you should be using GNU Emacs, nor am I going to tell you that you are an idiot for using VI (I was a hardcore, "down with emacs," VI user in the late 90s and early 00s). Instead, I'm going to talk about why Emacs works for me. If you're so inclined to give it a try after reading this, then so be it. Searching Google is bound to get you a ton of good information, or you could just start Emacs by typing emacs at the terminal and typing C-h (C- means hold down the control key and hit h [in this case]. M-key means hold down the Meta key [ALT on most keyboards] and hit key. If there's not a - between them, you can release Control or Meta before hitting the key).

I first started using Emacs in the spring of 2003, when an acquaintance at the time suggested that Emacs was superior and that I could even use viper-mode to simulate VI. The idea that a text editor was powerful enough to simulate another caught my curiosity. I fired it up, and hit the backspace key. Within moments I was put off when the Emacs equivalent of Clippy, came to my rescue.

See, Emacs responds logically to C-h, with "Help." The problem is that on many modern keyboards, the backspace key and C-h send the same value to the terminal.

So, I fired up Phoenix (or was it Firebird then? Maybe it was Fireweasel?) and searched Google for "emacs backspace problem." Within .004 seconds I had over 3 million pages telling me how to fix the problem. It said to add:

to my ~/.emacs file. So, I went to my terminal and did what anyone would have done in my situation—I typed vi ~/.emacs, pasted the snippet and ESC :wq!'d

But, despite my trouble I was intrigued. First of all, I had never seen a Unix program configured the way it was. Why didn't Emacs just use something like INI files, or some other simple format? Later, I realized that I wasn't just configuring Emacs—no, I was programming the editor to behave the way I preferred.

And, you'll say, "Well, how is that any different than configuration?" To, which I'll reply, "Every command you invoke, even the command that inserts the letter 'j' into this quote here, is calling a function written in the language I used before to set C-h to behave the way I preferred."

You see, Emacs isn't a text editor. Emacs is a programming language that you can use to write your own text editor. That's why viper-mode exists. Someone used Emacs to write VI.

And, as I read more about Emacs, and about all the editors people have written (that is to say, editors for writing C, Perl, Python, etc), I got more excited; that is until I discovered M-x tetris. Why does my editor need Tetris? It doesn't, and when I discovered more games, I got even more disgusted.

I'm not going to lie—not even a little bit, in 2003, Emacs was slow. Machines were getting faster, RAM like always was cheap, but it was torture to type emacs filename more than once a day. The games, and all this bloat were obviously the cause right? Well no. It turns out that Emacs has smart ways to load code, so you can save your precious memory. As a naive user, though, I was a bit upset.

So, off to Google again. "Google, How do I speed up Emacs?" "Well, my young Padawan," Google replied, "you should use the server. Add (server-start) (M-x describe-function RET server-start RET if you want more info) to your ~/.emacs file and connect with emacsclient." This was a few days later, and I had a cheat sheet on my desk, so I didn't escape to the terminal and start up VI. This time, I knew to chord C-x C-f, make my changes and chord C-x C-s. Easy-peasy.

The common theme here is that documentation for Emacs was easily accessible and there was a seemingly endless community of people answering questions about common pitfalls when getting started with Emacs. As a newbie, this fact made it extremely easy to want to continue learning, and as an advanced user today (can one ever gain the rank of Emacs expert?) this fact still draws me in.

Emacs has since gotten faster as a result of extremely cheap processing power, but VI of course still wins in startup time. It's not a very good metric for comparing the two pieces of software though. For one, I mentioned that Emacs had a server that you could use to keep Emacs going and connect with emacsclient, but I should also mention that I hardly ever use it. Emacs has an extensive file browser (with tab-completion!), and support for editing multiple files (called buffers). The other thing Emacs has is a mode called Tramp, which allows Emacs to edit files over SSH, FTP and many more. Since this is the case, keeping one Emacs session alive forever makes startup time nil. VI, on the other hand encourages relaunching with new files. I'm fairly sure modern VIs support editing more than one file at once, but I'm also pretty convinced that most VI users know about 15 things about VI, and multiple file editing isn't one of them.

The reason I even still have (server-start) in my ~/.emacs has to do with other utilities that need an editor. Invoking emacsclient filename will open filename in the Emacs instance that the server is running in. No startup lag—but you do unfortunately have to context switch.

Naturally, the Emacs community has solved this problem of context switch for many common cases. One of the places where you're bound to need to startup an editor as a programmer is when interacting with SCM tools such as Subversion, Mercurial or Git. These tools allow you to leave messages when you commit changes back to the repository. Committing is common, as is updating files and working with version control repositories in general, so it's only natural that your editor be version control aware. Emacs is, and uses vc-mode.

And the more you think about interactions with computers the more you realize how much of it is still text based. IRC, for instance is entirely text based, so why make it hard on yourself to switch back and forth between running programs when you can switch to an IRC buffer in Emacs? I do that, and it's wonderful.

Todo lists, calendars, calculators, Emacs does it all. It's no wonder that mere mortals joke about Emacs, saying "I'm happy with my operating system, I just want a decent text editor!" I said the same thing, and once I tried it, and took the time to learn it, I could never go back.

Extending

Over the years, I've discovered lots of things about Emacs, and new modes to play with. There's a never ending list of things to play with on EmacsWiki if you're so inclined.

As a programmer, writing my own enhancements was a matter of learning a bit about Emacs Lisp, the Lisp dialect that Emacs is built on. Coming from a background in C, Perl and at this point in time Python, I laughed at Lisp. "Why would anyone want to write that many parenthesis?" I've since come to the conclusion that Lisp is the most powerful set of programming languages available, but that is a topic for another day. (It is no coincidence, however that the most powerful text editor is built upon a dialect of the most powerful programming language.)

One of the first things I extended Emacs with was a way to convert Windows text files, which use carriage return and a line feed to something more appropriate for editing on Unix (line feed only). I came up with this with some help from our friend Google:

I'm fairly certain that I didn't write that completely from scratch, and I know for certain that I lifted the (if (looking-at...) ...) from the Internet somewhere as I'm not even sure why I would want to delete C-z characters from the end of the file.

Either way, the point is the same, now, without a context switch to the terminal, and the need to have the dos2unix package installed on my system, I can open a Windows text file and say, M-x dos2unix, and I'm in business.

Another utility that I decided I needed was the ability to split the current window in a 3/4, 1/4 configuration, instead of the default 1/2, 1/2 that you get when you call split-window. The result looks something like this:

Bound to a key, (global-set-key "\C-x7" 'three-quarters-window), makes it easy to keep an eye on an IRC buffer or something else that's changing a few lines at a time, while remaining relatively focused on the buffer you're really editing.

As I continue to try out new major modes and spend time programming Emacs to behave the way I want it to, it's only natural that my ~/.emacs file has become a bit large and hard to read. So I built something to fix it. I built something that allowed me to separate customizations into logical units. Basically, it works similarly to the init process from Unix.

I call my version activator. It's basically a few functions and a few overridable variables that will load a set of files with a specifically formatted file name in some specific location on your file system.

Using it is as simple as including a few lines in your ~/.emacs file:

By default activator will look for files in ~/.emacs.d/activator.d/ with the file name format XXdescription.el, where XX is a two digit number used for dependency resolution. In other words, 00settings.el will be loaded before 01utils.el if you were to have those files in your activator load path.

The code for doing this is surprisingly simple:

Of course, the real code defines the variables activator-filename-pattern and activator-load-path, which must be overridden before (activator-start) is run, should you decide you want to change them.

But, the real power in this is that I can rename configuration files to something that doesn't match the filename pattern if I don't want them to load, say because my configuration needs to be different at work, rather than at home. This makes my Emacs customizations pretty portable, and with a few more tweaks to the way activator works, I could make it even more portable.

I'm not going to be naive and think that I'm the first one to come up with something like this. I know for sure I'm not, and the only reason I did it myself was for the exercise of writing Emacs Lisp. All my customizations to Emacs are loaded currently with activator on all the machines that I use Emacs on. It's pretty great.

As a programmer who spends many hours a day using a text editor, the companionship that Emacs provides is a joy, and our relationship just keeps growing better as I uncover the stories and talents, my little friend has to share.