Alieniloquent

There’s this feature of TextMate that a lot of people like: the mate command. It opens up the file or directory you pass to it in your running TextMate instance.

This sort of feature isn’t anything new. Emacs has had this feature for a long time. You just add this snippet to your to your init.el:

Then you can use emacsclient to send files to it the same way. However, on my mac this wasn’t working. The trick, it seems, is making sure you use the correct emacsclient.

About a year ago, Emacs.app was merged into the main-line GNU Emacs. So you can build a completely Cocoa-based version of the very latest GNU Emacs right out of CVS. If you do that, an emacsclient executable is included in the application bundle.

You can write a little shell script, we’ll call it eopen:

Now, you’ll notice that in the failure case, my script sets some environment variables and just opens Emacs. Those environment variables aren’t anything special. In fact, unless you add some code to your init.el all you’ll get is a fresh Emacs open to whatever default buffer you usually see.

So, add the following to your init.el:

Then, when you have those environment variables set (such as in the shell script), emacs will open up a buffer on the file or directory passed in as an argument to the script. This hack is there so that you can use eopen to open non-existent files in addition to existent files (open complains if the file does not exist). Subsequent calls to the script can just use emacsclient.

For decades there’s been a war between zealous users of various editors. The truth is, though, that it is completely unfair to compare editors such as vi, Textmate, or BBedit with Emacs. Why is it unfair? Emacs isn’t an editor, it is a programming environment. Today I want to share an example just how powerful this distinction is.

It’s better to compare Emacs to Smalltalk. It has a very small core written in C, but almost all of the functionality you think of as Emacs is written in Emacs Lisp. Emacs is really just a Lisp interpreter with a lot of primitives built in for shuffling text around on the screen. This has a lot of awesome implications for people who want to build tools for programming.

For example, some people like to have a window pane that shows them the file structure of their project. Textmate does this. With nav you can have that in Emacs. However, it always puts the navigation on the left-hand side of the frame.

One of my co-workers wanted his nav to show up on the right-hand side. So I started by typing C-h k nav RET and that brought up the help for the function nav which puts the navigation buffer on the screen.

A quick terminology note. In Emacs-speak, operating-system windows are called frames. A frame can be split into multiple windows.

Doing the same for some of the other functions (split-window-horizontally, other-window, pop-to-buffer), I was able to determine what this function was doing. The call to split-window-horizontally leaves the right-hand window active, so the call to other-window hops back to the left-hand window (but only because all windows were deleted before the split). Then from there on out, everything assumes that it’s in that left-hand window and alters its behavior.

So, all we need to do is delete the line I bolded above and it should work. Because this is Lisp, I just copy the whole function into a buffer called *scratch*, make my edit, and evaluate the code. So, now when I type M-x nav RET I call my new function that does not call other-window. Sure enough, it shows up on the right-hand side.

However, I do not want to duplicate all the rest of that code. Emacs has an awesome facility to assist me, and it’s called defadvice.

This is essentially monkey-patching by another name. When I activate this advice it gets called instead of the function it’s advising, then at the point I call ad-do-it, the original function (and any previously defined advice) gets called. In the above code, I have two pieces of advice. One simply turns other-window into a no-op, and the other turns that on and off, but only if you use the universal prefix.

You can do this for any function in the system. Even the functions that get called when you hit individual keys. That is why Emacs is so powerful. It’s not an editor, it’s an environment.

I’m back!

My Spring got swallowed up by the tail-end of my last semester at UNO. Now it’s Summer and I’m living in San Francisco.

That’s right, I’m in San Francisco. I was planning on moving out here mid-July, but circumstances conspired such that I moved out here a week ago. I already have an apartment, and I’m getting settled in. I was hoping to get around and visit more of my friends in Omaha before I left, but hey, I’ll be visiting.

I am going to be blogging here again now that my brain isn’t getting drained (filled?) by school. My wife and I are also starting another blog to talk about general life stuff.

So Jay Hannah over at ODynUG has issued a programming challenge. Far be it from me to turn that kind of thing down. I am going to be doing this in Erlang.

Before I dive into coding on this, I want to give some thought to the algorithms I want to use in order to solve the problem. The way I tend to approach this is to consider what other problems I’ve solved, and see which this one looks the most like. Given my strong mathematics background, I tend to draw on theory-laden ideas. In this particular case I’m going to use graph theory. I plan to construct an interval graph, do some processing on it, and then find a coloring. I’ll then examine each color class, and find the one that produces the largest revenue.

The first step is to turn the raw demand data into an interval graph. In this graph, each individual demand will be represented by a vertex. An edge will be added to the graph between each demand that overlaps in time. At this point, we’re paying no attention to cats, dogs, small cages or large cages. All we want to see is how the demands overlap in time.

The second step is to group together the vertices that represent demands that can be met simultaneously. So picking a vertex, we’ll traverse all of its edges, and if we can combine two vertices in to one that represents them both, then we’ll do that. This presents an interesting problem, as the order in which we traverse the vertices makes a difference as to how many can be combined. However, it’s more likely that we’ll be able to combine demands if they have fewer pets or if their pets are smaller, so I’m going to traverse them in increasing order of pet quantity and size.

Next, we’ll find a coloring for the graph using the greedy coloring algorithm. To use this algorithm we need to pick a vertex ordering. Since the number of colors used can at most be one more than degree of the most connected vertex in the graph, and the greedy coloring algorithm relies on looking at the colors of previously colored neighbors, it makes sense to order the vertices in decreasing order of degree.

Armed with a coloring, we simply sum the rates for all of the demands in each color class, and then select the color that gives us the biggest revenue. The demands in that color are the ones that get accepted, the rest get rejected.

There are some drawbacks to this approach. For one, the graph coloring problem is NP-complete, so we cannot always be certain that the coloring we produce is the optimal coloring. Also, because of how we’re combining demands together, it is possible that a different combination would yield higher revenue. However, this algorithm should perform fairly well.

Okay, so I died a little.

I’ve been so busy, and writing on my blog has really just slipped my mind. Let alone working on side projects like blogerl or VUE.

Anyway, I’m back. I’m going to try and post at least once a week, if not more. I’m going to start off with some posts explaining how I’m going about solving a programming challenge for ODynUG.

So, the October ODYNUG meeting came and went, and it was great. My talk went well, despite my not having written my blogging tool.

It is amazing how busy a person can get with what seems like only a few things on his plate. Between my classes and work, I’ve been staying busy. I tried to do NaNoWriMo, but failed. I couldn’t even get a thousand words written because I am so busy.

I realized I hadn’t updated since September, and wanted to poke my head in and let you all know that in a month, I won’t be so busy. Come the middle of December, I’ll start working on blogerl again. I’ve made some design re-decisions. I’m basically going to be doing something similar to blosxom. It meshes well with my design goals, and I can even keep my posts in git if I want.

I just wanted to poke my head in and say that I’m still around, and still working on/thinking about the erlang project. I am, after all, still giving the talk next month.

I am, however, getting super busy with school. So, I’m having to sit down and schedule all of my non-work programming time. It’s looking like the erlang project isn’t going to get much love until after the end of September.

That said, when I get a few free moments this week, I’ll post some code I’ve already written that makes a nice interface around shelling out from erlang.

It was suggested that I use CouchDB as the storage engine for blogerl. I’m not going to be using CouchDB for this project, and I would like to explain why.

My reason for choosing Git over CouchDB is really just a preference. I think Git is neat, and I want to use it in a novel way. I’d like to demonstrate how it is a very powerful tool and can be used to do more that just version software. I think CouchDB is cool, and at some point, I’ll probably do a project with it. But, for this project, it’s not what I want.

In my previous post, I discussed the goals and priorities for blogerl. This time I am going to brainstorm some stories and prioritize them. Then I’ll select the first few from the prioritized list to be my first iteration. The goal is to have something I can deploy so I can get the blog started as soon as possible.

My philosophy for stories is to give them titles that are short. The story names are simply mnemonics to assist with recalling conversations and other details. Since I’m a team of one, the only conversations will be those I have here with you. But after this post, I’ll probably just refer to the stories by their title.

Here are the stories in priority order:

Storage

I need some way to store my posts. I’m not very choosy about how this is done. But, because I am in an experimental mood, I’m going to opt for using Git. I’m probably going to end up using Grit via erlectricity. There’s already been a wiki built on top of Git, why not a blog?

RESTful interface

Like I said before, I don’t want to compose my posts in a <textarea> but I do need to be able to get content into my application somehow. So, I’m going to design a RESTful interface to my data store. This is going to have to include an authentication mechanism, since I don’t want just anybody to be able to update or edit my blog.

Emacs mode

My preferred program for editing anything is Emacs. So it seems only natural that I’d choose to write my first REST client as an emacs mode.

Index

A front page that shows the posts in reverse chronological order. Should be paginated with 10 posts to a page.

Single

Permalinked pages for each individual post.

RSS

Add an RSS feed for the main index.

Atom

Add an Atom feed for the main index.

Archives

Provide archives based on year and month.

Templates

Templates for each of the views. Not YAWS pages. This will involve creating my own template language. I don’t like ErlTL for this as it is too programmery.

Caching

Keep rendered content in a cache with a TTL. Expire the cache for the index page if a post is added, edited or deleted. Expire the cache for a single post if it is edited or deleted.

Tags

Be able to specify an arbitrary number of tags to associate with a post. Provide archive pages for each tag.

Comments

Provide comments. They do not need to be threaded. Plain, flat comments are sufficient.

Trackbacks

Provide the ability for other blogs to post trackbacks.

Post-dating

Give the ability to submit a post that will be published at a later date.

Markdown

Add support for formatting a post in the Markdown formatting language.

Textile

Add support for formatting a post in the textile formatting language.

Formatting default

Add a configuration option specifying the default formatting (which starts out as plain HTML).

The first six are going to be what I aim to complete before I tag an 0.1 and deploy to my webserver. That’ll give me a means to share my blog posts with people as a stream or individually via their browsers or via RSS feeds.

First off, I’ve decided on a name for my project: blogerl. I will be hosting the source code here on GitHub.

With that bookkeeping out of the way, I’ll get to the meat of the post. I want to include you in my brainstorming process as I figure out what my goals are with this project. In my next post I’ll brainstorm features that will help me meet these goals and select a subset of those features to implement initially.

Before I can start brainstorming features, I need to figure out an overall vision for what I am trying to build. So the first thing I want to describe is the primary goal of this system, and possibly some secondary goals as well.

I want a system that will manage the storage and presentation of my blog content. That content will be primarily textual, and may be annotated with various pieces of meta-data (e.g. date, title, or tags).

That’s pretty vague, and I can design several extremely different systems that will deliver on that, so I’m going to provide some additional goals, in priority order, to narrow the design down.

Adding or editing content should be easy.

So many blogging tools are a pain to use. I’ll be honest, I’m not the biggest fan of the web application. Especially not for things like writing. I intend for Omniloquent to frequently have essays, and I don’t really like doing massive amounts of writing in a <textarea>.

Viewing the website should be fast.

This isn’t usually a problem in most modern blogging tools. However, I’m writing this one from scratch, so it’s going to be a little less modern at first. I don’t want people to be sitting around waiting for my content to load. I want it to be snappy. The closer to static content it feels, the happier I’ll be.

Adding or editing content should be fast.

The converse of the previous goal: I don’t want posting to take forever. This is why I hate Movable Type. The idea that I should have to rebuild dozens of pages when I just update a single post is ridiculous. However, I am willing to suffer a little, as I recognize that I’d rather it take me a second or two to post but have the blog be lightning fast for my readers. That said, the closer to instantaneous posting I can get, the happier I’ll be.