briancarper.net (λ) (Tag: Emacs)

org-mode is awesome

Thu, 20 Jan 2011 16:14:44 -0800

I've seen org-mode for Emacs mentioned very frequently around the interwebs, so it went into my mental queue of topics to learn. It finally bubbled to the top this week, so I took a look.

Organizer? Nah.

As an organizer/calendar, well, I doubt I'll need it. Enforced use of MS Outlook is mandated by work. My Post-it-notes-all-over-my-desk method of organization will also continue to serve me well.

There are some nice agenda-related shortcuts that are probably worth using though, like typing C-c . to enter a datestamp, like <2011-01-20 Thu>. Then you can increment or decrement it one year/month/day at a time via S-up and S-down. I like this.

Plaintext editor? Yes!

As a plaintext outline and table editor... wow. org-mode rocks. Do you know how many hours of my life could have been saved by having a good ASCII table/bullet-list editor? org-mode lines everything up and keeps it all nice and neat for you.

You can also make plaintext check boxes and check/uncheck them. And you can insert hyperlinks and footnotes, and click them to open web pages or jump back and forth between footnote and reference.

There are ways to collapse and expand outlines, search for items and only display those items, and so on. The documentation for org-mode is very clear and took me less than an hour to read through. All-in-all a pleasant experience.

* Agenda
** Things to learn
1. [X] Clojure
2. [X] org-mode (see [fn:diagram1])
3. [ ] Haskell
4. [ ] Japanese
   1. [X] Hiragana
   2. [X] Katakana
   3. [ ] Kanji
5. [ ] The true meaning of friendship

* Footnotes
[fn:diagram1]

| Task                              | Annoyance (1-10) |
|-----------------------------------+------------------|
| Making ASCII tables by hand       |              9.5 |
| Making ASCII bullet lists by hand |              7.2 |
| Using org-mode                    |              0.4 |

It looks nice plastered into my blog, but you don't get a real idea of how many cool things you can do with it until you open it in Emacs and start shuffling items around, bumping them up/down a level in headlines, creating properly-numbered bullet items with one key, and seeing the columns in the table auto-resize as you type.

I also highly recommend putting (setq org-startup-indented t) into .emacs to make everything look pretty on-screen. It still saves as the simple plaintext above, but it looks like this in Emacs:

I can definitely see using org-mode for TODO files in some of my projects. (You can mark entries as TODO (just by typing TODO in front), and then toggle between TODO/DONE via C-c C-t.) I can also see using it as a general-purpose note-taker.

org-mode also has a mobile version for iPhone and Android, synced via WebDAV or Dropbox, so you can org-mode on your phone while you're driving to the grocery store¹. Again I don't really need this, but there it is.

The joy of plaintext

Plaintext is awesome.

It's the universal file format. It's readable and writeable by scripting langauges, terminals, text editors, IDEs, word processors, web browsers, even lowly humans.

Plaintext's one shortcoming is its lack of structure. It's just a bunch of letters. It doesn't have a color, it doesn't have a style, it doesn't line up into columns without a lot of effort. There's nothing stopping you from opening a parenthesized list and forgetting the closing paren.

Computers don't care about these problems, but humans are bad at producting plaintext by hand, and bad at editing it once it's produced. Our clumsy, stumpy fingers and inconsistent, chaotic brains can't handle the freedom.

Emacs (and Vim) are awesome because they let you do magical things to plaintext. They enforce structure. They provide shortcuts so you can get your plainext right the first time.

[ ] is just two braces and a space, but org-mode lets me hit C-c C-c and turn the space into an X. This may seem banal, hardly worth caring about, but add to this shortcut thousands upon thousands of others. Things like org-mode, or paredit, or all of Vim's built-in magic... it all adds up to something wonderful.

And best of all, you always still have the option of manually keyboarding over and typing that X between the braces yourself. It's still just plaintext underneath. So you end up with the best of both worlds.

I do not recommend using org-mode while driving, for public safety reasons. ↩

Vim undo tree visualization

Mon, 18 Oct 2010 15:21:16 -0700

I wrote previously about an awsome plugin to give Emacs Vim-style undo trees.

Vim's undo trees are the best thing since sliced bread, but the interface for browsing through the tree is not pleasant. The Emacs undo-tree library has a way to visualize the tree and move through it with your keyboard, which solves this problem.

But now, thanks to Steve Losh, Vim has an undo-tree visualizer too. Delicious. Though it's still beta and promises to eat your babies, it seems to work pretty well. I think the diff view of the changes for the undo is a really good idea.

Thus continues the eternal Vim/Emacs arms race.

Emacs undo trees

Tue, 17 Aug 2010 14:06:33 -0700

I've said it before: undo in Emacs is horrible. On the other hand, undo in Vim is awesome.

But this is true no longer. Now there are undo trees for Emacs! Yes, this news is so important I had to italicize and bold it. It's like Emacs has been punching me in the face for years, and today I got it to stop. I never thought I'd see the day.

And it works great too. You can even view the tree visually and navigate it with the cursor keys, which is a step up on what Vim offers out of the box.

In other news, Vim 7.3 is out and it now has persistent undo across reloads. It's like an arms race, and gleeful hackers reap the benefits.

Emacs creating zombie buffers

Mon, 14 Jun 2010 15:44:18 -0700

Note to self:

Using bleeding-edge swank-clojure and Slime, Emacs was creating buffers that didn't point to any file, every time C-c C-k wanted to display warnings. This was really quite annoying as it resulted in a mess of empty buffers being created. This fixed it:

(setq slime-highlight-compiler-notes nil)

Emacs isn't for everyone

Tue, 08 Jun 2010 11:26:15 -0700

Chas Emerick recently posted the results of his State of Clojure survey. It turns out that the (self-selected) group of Clojure-using respondents happen to prefer Emacs as their IDE of choice, eclipsing all other editors by a large margin.

Chas then has this to say:

I continue to maintain that broad acceptance and usage of Clojure will require that there be top-notch development environments for it that mere mortals can use and not be intimidated by...and IMO, while emacs is hugely capable, I think it falls down badly on a number of counts related to usability, community/ecosystem, and interoperability.

As an avid, die-hard Vim and Emacs user for life, I'm going to agree.

Mere mortals?

Emacs isn't difficult to learn. Not in the sense of requiring skill or cleverness. It is however extremely painful to learn. I think there's a difference.

The key word is tedium. Learning Emacs is a long process of rote memorization and repetition of commands until they become muscle memory. If you're smart enough to write programs, you can learn Emacs. You just have to keep dumping time into the task until you become comfortable.

Until you're comfortable, you face the unpleasant task of un-learning all of your habits and forming new ones. And you're trying to do this at the same time you're undertaking another, even harder task: writing programs. And if you're a new Clojurist, and you're learning Emacs and Clojure from scratch at the same time, well, get the headache medication ready.

As a programmer and someone who sits in front of a computer 12+ hours a day, I consider myself pretty flexible and capable of picking up a new user interface. As someone who had been using Vim for years prior to trying Emacs, I considered myself more than capable of learning even a strange and foreign interface. I'd done it once before.

But learning Emacs still hurt. Oh how it hurt. I blogged while I was learning it, and you can see my pain firsthand. I sometimes hear people say "I tried Emacs for a whole month and I still couldn't get it". Well, it took me over a year to be able to sit down at Emacs and use it fluidly for long periods of time without tripping over the editor.

To be fair, I'm talking here about using Emacs as a programming environment. Using Emacs as a Notepad replacement could be learned in short order. C-x C-f, C-x C-s, or use the menus, there you go. Using it comfortably as a full-fledged IDE is significantly harder and requires you to touch (and master) many more features. Syntax highlighting, tab-completion, directory traversal and cwd issues, enabling line numbers, version-control integration, build tool integration, Emacs' funky regex syntax for search/replace, Emacs' bizarre kill rings and undo rings, the list goes on. These things are very flexible in Emacs, which is a great thing, but it's also an impediment to learning how to configure and use them. There's no getting around the time investment.

And it's not just a matter of learning some new keyboard shortcuts. There's a new vocabulary to learn. You don't open files, you visit them. What's a buffer? What's a window? (Not what you think it is.) What's a point? What's a mark? Kill? Yank? "Apropos"? Huh? C-c M-o means what exactly? My keyboard doesn't have a Meta key. Yeah, you can use CUA mode and get your modernized Copy/Cut/Paste shortcuts back, but that's the tip of the iceberg. It's hard even to know where to begin looking for help.

Yeah, Emacs came first, before our more common and more modern conventions were established, and that explains why it's so different. That doesn't change the fact that Emacs today is a strange beast.

Community and ecosystem

Personally I find the Emacs community to be a pretty nice bunch. In the highest tradition of hackerdom and open source software, Emacs users seem to be eager and willing to share their elisp snippets and bend over backwards to help other people learn the editor. I got lots of help when I was struggling and learning Emacs.

The Emacs wiki is an awesome resource. The official documentation is so complete (and so long) that it leaves me speechless sometimes. And there are a million 3rd-party scripts for it. Whatever you want Emacs to do is generally a short google away.

If there's anything wrong with the Emacs community, it'd be people who take Emacs evangelism overboard. The answer to "I don't want to have to use Emacs to use your language" can't be "Be quiet and learn more Emacs", or "If you're too dumb to learn Emacs, go away". In some communities there is certainly some of that. But thankfully I don't see it much in the Clojure community. Let's hope it stays that way.

Interoperability

Once someone spends the time to write a suitable amount of elisp, Emacs can interoperate with anything. I think so many people use SLIME for Clojure development precisely because it interoperates so darned well with Lisps. SLIME is amazing. You probably can't beat Paredit either, and Emacs' flexibility is precisely what makes things like Paredit possible.

The problem is the amount of time you have to spend to get that interoperability set up and to learn how to use it. After two years of using Emacs and Clojure together, every once in a while I still find myself bashing my face on my desk trying to get the latest SLIME or swank to work just right, or trying to get a broken key binding fixed, or tweaking some other aspect of Emacs that's driving me crazy. One day, curly braces stopped being recognized as matched pairs by Paredit. Why? No idea; I fixed it, but it was a half hour of wasted time.

Emacs is good at integrating with Git too. So good that there are four or five different Emacs-Git libraries, each with a different interface and feature set. I gave up eventually and went back to using the command line. (You can embed a shell / command line right in Emacs. There are three or four different libraries to do that too.)

The wealth of options of ways to do things in Emacs is simultaneously a good thing, overwhelming and confusing. If all you want is something that works and gets out of your way, too many options can be worse than one option, even if that one option isn't entirely ideal.

Emacs' Java interop, I know nothing about. Almost certainly, Emacs can come close to a modern Java IDE for fancy features like tab-completion and document lookups and project management. But how long is it going to take you to figure out that tab-completion is called hippie-expand in Emacs? That and a million other surprises await you.

What's my point?

There was a pithy quote floating around on Twitter a while back (I think quoting Rich Hickey):

One possible way to deal with being unfamiliar with something is to become familiar with it.

That's true, and you could say that of Emacs. I strongly believe that when it comes to computers, there's no such thing as "intuitive". There's stuff you've already spent a lot of time getting used to, and there's stuff you haven't.

But certain things require more of a time investment than others. Could I learn Clojure if all the keywords were in Russian or Chinese instead of my native English? Sure, but it'd take me a long time. I'd certainly have to have a good reason to attempt it.

I learned Emacs partly because it was hard. I saw it as a challenge. It was fun, yet painful, but more pain, more glory. Mastering it makes me feel like I've accomplished something. I'd encourage other people to learn Emacs and Vim too. I think the benefits of knowing them outweigh the cost and time investment of learning them.

But I didn't learn Emacs with the goal of being productive. I learned it for the same reason some people build cars in their garages, while most people just buy one and drive it to and from work every day. I learned Emacs because I love programming and I love playing with toys, and Vim or Emacs are as nice a toy as I could ask for. (I love programming enough to form strong opinions and write huge blog posts about text editors.) For me, productivity was a beneficial side-effect.

There are only so many hours in a day. There are a lot of other challenges to conquer, some of which offer more tangible benefits than Emacs mastery would get you. Mastering an arcane text editor isn't necessarily going to be on the top of the list of everyone's goals in life, especially when there are other editors that are easier to use and give you a significant subset of what Emacs would give you. We have to pick our battles.

So I understand when people say they don't want to learn Emacs. I think maybe so many Clojurists use Emacs right now because we're still in the early adopter stage. If you're using Clojure today, you're probably pretty enthusiastic about programming. You're likely invested enough to be willing to burn the required time to learn Emacs.

If Clojure becomes "big", there are going to be a lot of casual users. A casual user of Clojure isn't going to learn Emacs. They're going to silently move on to another language. And I really think that new blood is vital to the strength of a community and necessary for the continued healthy existence of a programming language.

So Clojure does need alternatives. I'll stick with Emacs myself, but there should be practical alternatives. I'd encourage the Clojure community to continue to support and enjoy Emacs, but don't push it too hard.

Emacs: Yank lines as lines

Fri, 21 May 2010 12:07:13 -0700

One thing nice about Vim is manipulating whole lines at a time. dd deletes a line (including trailing newline), regardless of where the cursor is on the line. Then, p puts that line (with its newline) as a new line after the current line, and P puts it above the current line, again regardless of where your cursor is at the moment. (It also jumps the cursor to the beginning of the text you just inserted, which is nice.)

Emacs has kill-whole-line (C-S-Backspace) which is like Vim's dd. But I didn't find an equivalent of p and P. So here's my version:

(defun yank-with-newline ()
  "Yank, appending a newline if the yanked text doesn't end with one."
  (yank)
  (when (not (string-match "\n$" (current-kill 0)))
    (newline-and-indent)))

(defun yank-as-line-above ()
  "Yank text as a new line above the current line.

Also moves point to the beginning of the text you just yanked."
  (interactive)
  (let ((lnum (line-number-at-pos (point))))
    (beginning-of-line)
    (yank-with-newline)
    (goto-line lnum)))

(defun yank-as-line-below ()
  "Yank text as a new line below the current line.

Also moves point to the beginning of the text you just yanked."
  (interactive)
  (let* ((lnum (line-number-at-pos (point)))
         (lnum (if (eobp) lnum (1+ lnum))))
    (if (and (eobp) (not (bolp)))
        (newline-and-indent)
      (forward-line 1))
    (yank-with-newline)
    (goto-line lnum)))

(global-set-key "\M-P" 'yank-as-line-above)
(global-set-key "\M-p" 'yank-as-line-below)

Just one more step along the path to Vimmify my Emacs setup. Emacs has some weird edge cases because you can move the cursor one "line" past the last real line in the file. But I think I worked out something comfortable for myself.

PS: I've written about this before, but if you use C-S-Backspace a lot in Emacs on Linux, I highly recommend putting this into your X11 config:

Option "DontZap" "True"

It's really easy to mix up C-S-Backspace and C-M-Backspace (the latter of which kills your X server). It's not fun to mix those up. Not fun at all.

PPS: This thread on Stack Overflow has some Emacs equivalents of Vim's o and O which are pretty nice too.

Vim vs. Emacs: Indenting text before copying

Thu, 13 May 2010 16:21:27 -0700

I use Markdown on my blog for posts and comments, and I post at other sites that use Markdown (e.g. Stack Overflow). In Markdown, text indented four spaces is displayed as code, in pre tags.

I find myself often writing code in Vim or Emacs and needing to copy/paste it into a browser in a Markdown-suitable way.it back. This is easy to do in Vim and Emacs, only a few keystrokes. But "a few" is still greater than "one", so the heck with that. Let's script it.

Vim version

This keymapping in Vim will do it all for me:

vmap <Leader>y :s/^/    /<CR>gv"+ygv:s/^    //<CR>

One clumsy thing about Vim is needing to restore the previous visual selection after each regex-replacement. I could use the marks '< and '> as ranges to :s instead, but that's more typing than simply doing gv in the mapping. Copying to the system clipboard is easy because Vim has a register "+ for that purpose.

This took me maybe 45 seconds to write, probably due to being pretty familiar with Vim already. But in Vim, mappings are easy. You just type the characters that you'd type if you were doing it manually.

Emacs version

Trying to do the same in Emacs was painful. My Emacs-fu is sorely inadequate, compared to my Vim-jitsu. This seems to work, but ugh:

;; adapted from http://www.emacswiki.org/emacs/.emacs-ChristianRovner.el
(defun expand-region-linewise ()
  (interactive)
  (let ((start (region-beginning))
        (end (region-end)))
   (goto-char start)
   (beginning-of-line)
   (set-mark (point))
   (goto-char end)
   (unless (bolp) (end-of-line))))

(defun markdown-copy ()
  (interactive)
  (save-window-excursion
   (save-excursion
     (save-restriction
       (expand-region-linewise)
       (narrow-to-region (region-beginning) (region-end))
       (goto-char (point-min))
       (replace-regexp "^" "    ")
       (clipboard-kill-ring-save (point-min) (point-max))
       (goto-char (point-min))
       (replace-regexp "^    " "")))))

Writing this involved a long journey through the Emacs documentation.

One difficulty was getting Emacs to play friendly with my fat-fingered region-marking. I don't always highlight from the beginning of the first line to the end of the last. That's why Vim's visual-line mode is awesome; the cursor can be anywhere on the line, it still selects the whole line. The handy function above (found on the Emacs wiki) takes care of that. I don't know how long it would've taken me to come up with that on my own.

Then it was a matter of rooting through millions of Emacs functions until I found the ones that move the point around and copy text to the clipboard. Along the way I discovered the wonders of "narrowing", which limits Emacs to work on some region of text, and all those macros to undo the messes I make while moving around.

Maybe I could've done this with an Emacs keyboard macro, and then called apply-macro-to-region-lines. And maybe I could use append-next-kill to build up the indented text one line at a time. But my efforts to do this or anything like it failed horribly.

In any case I thought it was an interesting comparison. Improvements to either version are welcome.

EDIT: This works too (thanks Holger Durer):

(defun markdown-copy ()
  (interactive)
  (save-excursion
    (expand-region-linewise)
    (indent-rigidly (region-beginning) (region-end) 4)
    (clipboard-kill-ring-save (region-beginning) (region-end))
    (indent-rigidly (region-beginning) (region-end) -4)))

Deploying Clojure websites

Mon, 04 Jan 2010 20:42:17 -0800

On my server I'm running one Java process, which handles four of my websites on four different domains. These are all running on Clojure + Compojure. Some people asked for details of how to do this, so here's a rough outline. For the sake of brevity I'm only going to talk about two domains here, though it scales up to however many you want pretty easily.

This is surely not the only way to do this, and probably not the best way, but it's what I've arrived at after a year of goofing off.

Summary: Emacs + SLIME + Clojure running in GNU Screen; all requests are handled by Apache and mod_proxy sends them to the appropriate Jetty instance / servlet.

Directory structure

First you have to decide on a directory structure. There's a sort of Clojure convention to have a src and deps directory, though Clojure is so young that this convention may or may not stick. Behold my ASCII line-art directory tree:

~/public_html/base/
|
|----src/
|    |
|    |----common/
|    |
|    |----net/
|         |
|         |----briancarper/
|         |    |
|         |    |----<lots of .clj files>
|         |
|         |----ffclassic/
|              |
|              |----<lots of .clj files>
|
|----deps/
|    |
|    |----<lots of .jar files>
|
|----briancarper.net/
|    |
|    |----public/
|    |
|    |----db/
|    |
|    |----apache/
|
|----ffclassic.net/
|    |
|    |----public/
|    |
|    |----apache/
|

src holds the Clojure source code for all of my sites. Java (therefore Clojure) forces your directory structure to match your namespaces, and traditionally people use domain names in reverse order for both. Whether you like or dislike this convention, you must admit that if you're writing code that's actually going to be used to host websites on domains, the convention probably makes sense. There are some utility libraries I wrote that I like to share between sites, so I put those in some common namespace in their own directory.

deps holds a bunch of .jar files. This includes clojure.jar, clojure-contrib.jar, compojure.jar, swank-clojure.jar (for SLIME), and all the Java libraries I use, like Jetty, a bunch of Apache Commons libraries, Tokyo Cabinet, Rhino and so on. This means that all of my sites are sharing libraries, and therefore must be running the same version of Clojure and all other libraries. So when I upgrade a library that one site is using, I must upgrade all the other sites. This is sometimes a hassle, but it forces me not to be lazy.

Then I have one more directory for each of my domains, for static files and such. These directories have different subdirectories depending on how I'm running them. For the sites that use Tokyo Cabinet, I have a db directory to hold the database files. On some sites I want to run a PHP or CGI script, so I have a directory for Apache to use. All of them have a public folder, from which Clojure serves images, JS and CSS files etc.

Phil Hagelberg's recent Leiningen project can possibly help with some of this. I don't use Lein but I may switch someday.

Emacs + SLIME + CLASSPATH setup

Building or installing Clojure and Emacs and SLIME and friends is beyond the scope of this blog post. swank-clojure has come a long way in being auto-installable via ELPA nowadays, if you like.

The most important thing is to set up CLASSPATH correctly. src should be on the CLASSPATH, as well as every .jar file in deps. My .emacs contains this, among other things:

(setq swank-clojure-classpath (list "." "./src" "./deps/*"))
(setq swank-clojure-library-paths (list "/usr/local/lib"))

Java will take a glob and expand it to include every jar file in a directory, thankfully. But this seems to happen right when you start Java, so to add a new .jar to your CLASSPATH you generally need to restart the JVM. This is annoying, but oh well.

If you AOT-compile your Clojure code you might also have a classes folder on your classpath, but I don't bother. You could also compile your whole site into its own .jar file and use that. I don't do this because I want to be able to edit my Clojure source files on the server if I need to.

swank-clojure-library-paths is necessary for me because Tokyo Cabinet uses some C libraries. You might not need it.

Then when I start Emacs, I M-x cd to the base folder and start SLIME there. It'll find Clojure in deps and give me a REPL. If you can get this working, you're well on your way.

Clojure code

I have a file server.clj for each domain, which are in charge of setting up and starting / stopping the servlets. So in src/net/briancarper/server.clj I have something like:

(ns net.briancarper.server
  (:use (compojure.http request servlet session routes)
        (compojure.server jetty)
        (compojure control)
        (net.briancarper ...)))  ;; lots of files containing the guts of the site

(defroutes some-routes ...)
(defroutes other-routes ...)

(defroutes all-routes
  some-routes
  other-routes)

(defserver blog-server
  {:port 8080 :host "localhost"}
  "/*" (servlet all-routes))

src/net/ffclassic/server.clj is similar, except with different routes (obviously) and a different port for the servlet. Note that we bind to localhost here, so that people can't connect directly to port 8080 and bypass Apache.

One of the routes should be set up to point to the proper public folder. Generally some catch-all route near the end of your list of routes, like:

(GET "/*" (static-file (params :*)))

where this static-file knows to serve files from briancarper.net/public, and the other server.clj for the other domains point to different directories.

Compojure has the compojure.http.helpers/serve-file function you can use to serve static files too. I use my own function for various reasons. Note that Compojure generally doesn't set any HTTP headers on your responses. You should probably set some kind of cache control headers unless you want your users to re-download all of your image files and stylesheets every time they hit a new page. You might also have to fiddle with Content-Type sometimes, though Compojure is usually pretty good about guessing them.

Note that Compojure's hands-off approach has its upsides too. For example, I have a bunch of CSS files for my blog. In Clojure, I read and concatenate all of those CSS files into one blob of text and have Clojure serve that as http://briancarper.net/combined.css. combined.css doesn't actually exist. I do the same for JS. This speeds up user requests quite a bit, without having to merge all the files on the filesystem. I could further compactify them if I cared.

If your Clojure app is handling arbitrary request URIs, you should be careful you aren't serving up ../../../../etc/passwd or something. Pretty sure Apache protects you against this by default, but Compojure uses compojure.http.helpers/safe-path? to test for it too if you use the built-in serve-file.

Finally, for convenience, in the base directory I have a file called server.clj which contains this:

(ns server
  (:require [net.briancarper server]
            [net.ffclassic server]))

(defn go []
  (.start net.briancarper.server/blog-server)
  (.start net.ffclassic.server/ffclassic-server))

Then, to start everything, from a REPL:

user> (require 'server)
2010-01-04 18:10:50.046::INFO:  Logging to STDERR via org.mortbay.log.StdErrLog
net.briancarper.server.proxy$javax.servlet.http.HttpServlet$0
net.ffclassic.server.proxy$javax.servlet.http.HttpServlet$0
nil
user> (server/go)
2010-01-04 18:11:02.260::INFO:  jetty-6.1.15
2010-01-04 18:11:02.358::INFO:  Started SocketConnector@localhost:8080
2010-01-04 18:11:02.707::INFO:  jetty-6.1.15
2010-01-04 18:11:02.789::INFO:  Started SocketConnector@localhost:8087
nil
user>

On the server (Apache)

To deploy this to my server I just rsync it all over SSH. On the server, I have Emacs and Java installed, as well as Apache and GNU Screen.

Why Apache? In case I want to run something that isn't Clojure, like webmail or some CGI script. Plus it's easy to run Clojure as a non-priviledged user on a non-priviledged port, and have Apache forward requests to the proper servlet based on the domain in the request. Apache is also nice for doing HTTPS.

My Apache setup is a pretty standard Debian-ish setup. You need mod_proxy installed. My Apache config for one domain looks a bit like this:

<VirtualHost *:80>
        ServerName ffclassic.net
        ServerAlias www.ffclassic.net

        <Directory /home/user/clj/ffclassic.net/apache/>
           AllowOverride All
           Order Allow,Deny
           Allow from all
        </Directory>

        DocumentRoot /home/user/clj/ffclassic.net/apache/

        ProxyPass /foo !
        ProxyPass / http://localhost:8087/
        ProxyPassReverse / http://localhost:8087/
</VirtualHost>

Yeah, that's about it. By default, every request will be passed to Clojure. The ports specified here should obviously match the ports you specify in your Clojure code for your servlets.

ProxyPass /foo ! tells Apache to handle requests to http://ffclassic.net/foo itself rather than pass them to Clojure. I override URIs on a case-by-case basis like this, to tell Apache to run whatever CGI or PHP scripts I need.

One oddity of running a setup like this is that thanks to mod_proxy, the "remote address" for every request is always going to be 127.0.0.1 by the time they get to Clojure. So if you want to see the IP address of your users, you have to do something like:

(defn- ip [request]
  (or ((:headers request) "x-forwarded-for")
      (:remote-addr request)))

Another oddity is that sometimes if Apache is running, and then I start Clojure, I have to restart Apache before it "finds" Clojure and starts forwarding traffic. No big deal though.

This is otherwise transparent from the Clojure end.

Starting it up

You probably want to SSH to your server, start a REPL, start your code running, and then log off the server. There are various ways you can run keep Emacs running in the background. You could run Emacs in server mode and attach to it with emacsclient. I use GNU Screen because it's easy and I have other things running in Screen instances that I like to switch between. So I start Screen, start Emacs, start SLIME, and start my site from there. Then detach from Screen when I'm done. It's easier than it sounds.

Why SLIME and not a normal commandline REPL? Because in Emacs I can patch the code easily on a function-by-function basis, among other things. You can do this from a commandline REPL but not nearly as easily. Emacs is a much nicer place to type than any command line. When I need to make an update to the site or fix a bug, my workflow is typically:

Fix it locally on my test machine, make sure it works
rsync the changed files to the server
SSH to the server
screen -r to bring up Emacs
Open the .clj file(s) I changed
C-c C-c to recompile and reload the individual function(s) I changed, or C-c C-k to recompile and load a whole .clj file, or whatever.
C-a d to detach from Screen

I can do any database inspecting or fiddling I need to do from the REPL. I can also do some live testing of the site or whatever else I want. It's good for debugging.

I've had Emacs running for months this way without having to restart it, it seems to work OK.

That's it

It's not that hard. It's clearly more steps than dumping some PHP files into a directory and having them work. But with Clojure, you get the benefit of a persistently running environment with a nice REPL interface, all in a nice fast multi-threaded JVM. Plus you get to write all your code in Clojure instead of PHP. In terms of fun and long-term maintenance costs, Clojure comes out way ahead in the end, for me anyways.

Emacs Clojure colors

Fri, 30 Oct 2009 19:02:14 -0700

In yet another step along the path of trying to forcibly morph Emacs into Vim, I started a port of my Vim color scheme Gentooish to an Emacs color-theme.

Then I threw a few lines at the bottom of .emacs to highlight a few more Clojure-specific things when in clojure-mode. Result:

This is inspired partly by parenface.el which dims parens so they don't stand out as much. Lispers have this silly meme where they pretend they can't see parens at all, but being a mere human I want Emacs to help blend them into the background a bit.

I want to dim parens but also make braces and brackets pop out a bit more. Coloring braces, brackets and parens slightly differently helps make a few things easier to read in my opinion, especially in ))]}])) kinds of situations (like at the end of the function above).

This is pretty brute-force and I really wish I could figure out how to highlight #{} (sets) differently than {} (hash-maps). Highlighting (), '(), `(), and #() differently would be awesome too. But that is well beyond my elisp skills at the present. Certain areas of Emacs are all but impenetrable, no matter how much documentation I read and how much banging on the keyboard I do. The morass that is font-lock is one of those areas.

p.s. I find an easy way to keep your dotfiles in git is to make a folder (called dotfiles or something) and symlink your dotfiles from there to your home directory. I also put * in .gitignore so git doesn't slurp up anything sensitive by accident.

searchpairpos

Thu, 20 Aug 2009 14:39:03 -0700

How did I live this long without knowing about searchpairpos() in Vim? I hate when I write a clumsy, slow reimplementation of something that already exists as a standard function.

The only bad thing about Vim and Emacs both is that the feature list is about a mile and a half long (and that's a bad thing only in the sense of being an overwhelming amount of good things).

I have read almost the entire Vim manual at this point but there are corners that remain unexplored, and sometimes they contain treasure. One thing I love doing is answering Vim questions on Stack Overflow because most of the time I don't know the answer right off the bat, and so looking it up or figuring it out teaches me something new.

Emacs is another story... Emacs remains a mystery to me in many ways, in spite of having used it for about a year now. I very much plan to read the whole Emacs manual. I've already read parts of it but I seem to have barely made a dent. There are things I know should be simple to do or that there are already built-in options for, but I don't know how to do them.

How do I kill a word and also kill the whitespace immediately after it so it yanks properly later?
When I kill-whole-line and paste that line elesewhere, I lose a newline and screw up indenting. Sometimes it works how I expect and sometimes it doesn't.
There are so many things I can do in Vim but can't in Emacs... marks, multiple registers, abbreviations, sensibly configured per-filetype indentation.

etc. etc. I know there are ways to do these things once I have time to just sit down and read the darned manual. And learn elisp's syntax and semantics (which can't be harder than learning Vim script). My ~/.vimrc is currently twice as long as my ~/.emacs, which says a lot.

On a related note, I'm in the process of putting my Vim and Emacs configs on github.

Vim and Emacs modelines

Tue, 05 May 2009 18:22:47 -0700

Both Vim and Emacs have "windows", resizeable panes inside the main app "frame". Windows are a very useful feature (aside from the ill-chosen name; should've been "panes" or something). I find windows superior to tabs in my opinion; you can easily view more than one file at a time, view two files side-by-side for comparison, and such. Both Vim and Emacs use the border under the window to show helpful information like the filename and editing mode such; this is called the "status line" or "modeline". Again, very handy.

How do you set a nice custom modeline in Vim? Here's my config from my .vimrc:

set statusline=%f\ %2*%m\ %1*%h%r%=[%{&encoding}\ %{&fileformat}\ %{strlen(&ft)?&ft:'none'}\ %{getfperm(@%)}]\ 0x%B\ %12.(%c:%l/%L%)

Yikes! What a mess. It's just a big string with a bunch of special codes and literal characters all mixed up. If you do :h 'statusline' you can read about all the options. That string is ugly though.

Or so I thought, until I witnessed the trainwreck that is Emacs. The documentation for Emacs' modeline comprises a small encyclopedia. The configuration itself is spread across a couple dozen configuration variables. This is the default value for just one of them:

(#("%[" 0 2
   (help-echo "Recursive edit, type C-M-c to get out"))
 #("(" 0 1
   (help-echo "mouse-1: Select (drag to resize)\nmouse-2: Make current window occupy the whole frame\nmouse-3: Remove current window from display"))
 (:propertize
  ("" mode-name)
  help-echo "Major mode\nmouse-1: Display major mode menu\nmouse-2: Show help for major mode\nmouse-3: Toggle minor modes" mouse-face mode-line-highlight local-map
  (keymap
   (mode-line keymap
          (down-mouse-3 keymap
                (abbrev-mode menu-item "Abbrev (Abbrev)" abbrev-mode :help "Automatically expand abbreviations" :button
                     (:toggle . abbrev-mode))
                (auto-fill-mode menu-item "Auto fill (Fill)" auto-fill-mode :help "Automatically insert new lines" :button
                        (:toggle . auto-fill-function))
                (auto-revert-mode menu-item "Auto revert (ARev)" auto-revert-mode :help "Revert the buffer when the file on disk changes" :button
                          (:toggle bound-and-true-p auto-revert-mode))
                (auto-revert-tail-mode menu-item "Auto revert tail (Tail)" auto-revert-tail-mode :help "Revert the tail of the buffer when buffer grows" :enable
                           (buffer-file-name)
                           :button
                           (:toggle bound-and-true-p auto-revert-tail-mode))
                (flyspell-mode menu-item "Flyspell (Fly)" flyspell-mode :help "Spell checking on the fly" :button
                       (:toggle bound-and-true-p flyspell-mode))
                (font-lock-mode menu-item "Font Lock" font-lock-mode :help "Syntax coloring" :button
                        (:toggle . font-lock-mode))
                (glasses-mode menu-item "Glasses (o^o)" glasses-mode :help "Insert virtual separators to make long identifiers easy to read" :button
                      (:toggle bound-and-true-p glasses-mode))
                (hide-ifdef-mode menu-item "Hide ifdef (Ifdef)" hide-ifdef-mode :help "Show/Hide code within #ifdef constructs" :button
                         (:toggle bound-and-true-p hide-ifdef-mode))
                (highlight-changes-mode menu-item "Highlight changes (Chg)" highlight-changes-mode :help "Show changes in the buffer in a distinctive color" :button
                            (:toggle bound-and-true-p highlight-changes-mode))
                (outline-minor-mode menu-item "Outline (Outl)" outline-minor-mode :help "" :button
                        (:toggle bound-and-true-p outline-minor-mode))
                (overwrite-mode menu-item "Overwrite (Ovwrt)" overwrite-mode :help "Overwrite mode: typed characters replace existing text" :button
                        (:toggle . overwrite-mode))
                "Minor Modes")
          (mouse-2 . describe-mode)
          (down-mouse-1 menu-item "Menu Bar" ignore :filter
                (lambda
                  (_)
                  (mouse-menu-major-mode-map))))))
 ("" mode-line-process)
 (:propertize
  ("" minor-mode-alist)
  mouse-face mode-line-highlight help-echo "Minor mode\nmouse-1: Display minor mode menu\nmouse-2: Show help for minor mode\nmouse-3: Toggle minor modes" local-map
  (keymap
   (header-line keymap
        (down-mouse-3 keymap
                  (abbrev-mode menu-item "Abbrev (Abbrev)" abbrev-mode :help "Automatically expand abbreviations" :button
                       (:toggle . abbrev-mode))
                  (auto-fill-mode menu-item "Auto fill (Fill)" auto-fill-mode :help "Automatically insert new lines" :button
                          (:toggle . auto-fill-function))
                  (auto-revert-mode menu-item "Auto revert (ARev)" auto-revert-mode :help "Revert the buffer when the file on disk changes" :button
                        (:toggle bound-and-true-p auto-revert-mode))
                  (auto-revert-tail-mode menu-item "Auto revert tail (Tail)" auto-revert-tail-mode :help "Revert the tail of the buffer when buffer grows" :enable
                             (buffer-file-name)
                             :button
                             (:toggle bound-and-true-p auto-revert-tail-mode))
                  (flyspell-mode menu-item "Flyspell (Fly)" flyspell-mode :help "Spell checking on the fly" :button
                         (:toggle bound-and-true-p flyspell-mode))
                  (font-lock-mode menu-item "Font Lock" font-lock-mode :help "Syntax coloring" :button
                          (:toggle . font-lock-mode))
                  (glasses-mode menu-item "Glasses (o^o)" glasses-mode :help "Insert virtual separators to make long identifiers easy to read" :button
                        (:toggle bound-and-true-p glasses-mode))
                  (hide-ifdef-mode menu-item "Hide ifdef (Ifdef)" hide-ifdef-mode :help "Show/Hide code within #ifdef constructs" :button
                           (:toggle bound-and-true-p hide-ifdef-mode))
                  (highlight-changes-mode menu-item "Highlight changes (Chg)" highlight-changes-mode :help "Show changes in the buffer in a distinctive color" :button
                              (:toggle bound-and-true-p highlight-changes-mode))
                  (outline-minor-mode menu-item "Outline (Outl)" outline-minor-mode :help "" :button
                          (:toggle bound-and-true-p outline-minor-mode))
                  (overwrite-mode menu-item "Overwrite (Ovwrt)" overwrite-mode :help "Overwrite mode: typed characters replace existing text" :button
                          (:toggle . overwrite-mode))
                  "Minor Modes"))
   (mode-line keymap
          (down-mouse-3 keymap
                (abbrev-mode menu-item "Abbrev (Abbrev)" abbrev-mode :help "Automatically expand abbreviations" :button
                     (:toggle . abbrev-mode))
                (auto-fill-mode menu-item "Auto fill (Fill)" auto-fill-mode :help "Automatically insert new lines" :button
                        (:toggle . auto-fill-function))
                (auto-revert-mode menu-item "Auto revert (ARev)" auto-revert-mode :help "Revert the buffer when the file on disk changes" :button
                          (:toggle bound-and-true-p auto-revert-mode))
                (auto-revert-tail-mode menu-item "Auto revert tail (Tail)" auto-revert-tail-mode :help "Revert the tail of the buffer when buffer grows" :enable
                           (buffer-file-name)
                           :button
                           (:toggle bound-and-true-p auto-revert-tail-mode))
                (flyspell-mode menu-item "Flyspell (Fly)" flyspell-mode :help "Spell checking on the fly" :button
                       (:toggle bound-and-true-p flyspell-mode))
                (font-lock-mode menu-item "Font Lock" font-lock-mode :help "Syntax coloring" :button
                        (:toggle . font-lock-mode))
                (glasses-mode menu-item "Glasses (o^o)" glasses-mode :help "Insert virtual separators to make long identifiers easy to read" :button
                      (:toggle bound-and-true-p glasses-mode))
                (hide-ifdef-mode menu-item "Hide ifdef (Ifdef)" hide-ifdef-mode :help "Show/Hide code within #ifdef constructs" :button
                         (:toggle bound-and-true-p hide-ifdef-mode))
                (highlight-changes-mode menu-item "Highlight changes (Chg)" highlight-changes-mode :help "Show changes in the buffer in a distinctive color" :button
                            (:toggle bound-and-true-p highlight-changes-mode))
                (outline-minor-mode menu-item "Outline (Outl)" outline-minor-mode :help "" :button
                        (:toggle bound-and-true-p outline-minor-mode))
                (overwrite-mode menu-item "Overwrite (Ovwrt)" overwrite-mode :help "Overwrite mode: typed characters replace existing text" :button
                        (:toggle . overwrite-mode))
                "Minor Modes")
          (mouse-2 . mode-line-minor-mode-help)
          (down-mouse-1 . mouse-minor-mode-menu))))
 #("%n" 0 2
   (local-map
    (keymap
     (mode-line keymap
        (mouse-2 . mode-line-widen)))
    mouse-face mode-line-highlight help-echo "mouse-2: Remove narrowing from the current buffer"))
 #(")" 0 1
   (help-echo "mouse-1: Select (drag to resize)\nmouse-2: Make current window occupy the whole frame\nmouse-3: Remove current window from display"))
 #("%]" 0 2
   (help-echo "Recursive edit, type C-M-c to get out"))
 #("--" 0 2
   (help-echo "mouse-1: Select (drag to resize)\nmouse-2: Make current window occupy the whole frame\nmouse-3: Remove current window from display")))

What the hell?

Instead of a string, it's an s-expression, which is better, right? Well no, it's still just a big construct with arbitrary meanings assigned to its contents. Lists mean one thing, strings mean another thing (and those strings, like Vim's, can contain special escape sequences). Symbols mean something else, symbols that are keywords mean something else, numbers mean something else, and so on.

To decipher this I had to learn this mini-language. And also learn about "text properties" and a bunch of elisp stuff. It also required knowledge about a bunch of minor modes and how they tie into the modeline, all of which is essentially a bowl of spaghetti code. And keymaps, and maps to control mouse click events and such. Eventually I figured out that most of that crap is controlling tooltip text.

If you do M-x customize-apropos in Emacs and search for "mode-line", you'll get a helpful list of all of the configuration values and their values. (The default values contain literal tab characters, which you can't even type into the customize text fields without C-qing, because tab jumps you between fields. Ughhhhhhh.)

I gave up even trying to get Emacs to have all the helpful information my Vim modeline has. Even deleting the default crap to pare this down to something readable took some effort. This what I ended up with:

(mode-line-format (quote ("%e--[" mode-line-buffer-identification "]" (vc-mode vc-mode) "  " mode-line-modes global-mode-string " %-")))
(mode-line-in-non-selected-windows t)
(mode-line-modes (quote ("%[" "(" (:propertize ("" mode-name)) ("" mode-line-process) (:propertize ("" minor-mode-alist)) "%n" ")" "%]")))
(mode-line ((((class color) (min-colors 88)) (:background "#333333" :foreground "#bcbcbc" :box (:line-width -1 :color "#333333")))))
(mode-line-highlight ((((class color) (min-colors 88)) nil)))
(mode-line-inactive ((default (:inherit mode-line)) (((class color) (min-colors 88) (background dark)) (:foreground "#8b8b8b" :weight light))))

What does that mean? Don't ask me, I can no longer read it. If customize hadn't produced a lot of that for me, I probably wouldn't have managed. My favorite part is the four-deep nested list of lists of lists of lists for the colors.

Verdict?

Vim's modeline is less powerful than Emacs. But who cares if you can't even read it to edit it? Most of Emacs' modeline features are annoying. (My motivation for editing this to begin with was to turn off all the mouse buttons and mini-menus and crap.)

Vim's status line is exactly configurable enough. I don't want to build a small GUI app in my modeline. I want it to show certain bits of information about the buffer, that's it. Vim does this.
Vim script is less elegant than elisp. Or is it? Vim's modeline is a custom DSL for formatting modelines. It's hard to think of anything more concise. Concision is a very good thing. Emacs' version is more general, at the expense of horrid verbosity and unreadability.
Vim's modeline is a string, which means you either write it literally, or you construct it by concatenating lots of other strings. This is a faux pas, right? It's like using eval in Ruby or Perl. It's fragile and error-prone. Emacs uses a Lisp, with its macros and quoted lists and code is data and so on.

But who cares? In this case, a simple string is powerful enough. I don't need a whole Turing-complete programming language to configure a modeline. It's massive overkill and you pay a price for it. The minute a human being is supposed to be keeping track that the second element in the 5-deep nested list means "x", something has gone horribly wrong.

Vim wins this round.

A Sad, Dark Day

Mon, 13 Apr 2009 01:27:12 -0700

Today was a terrible day. I found myself subconsciously trying to use Emacs keystrokes in Vim. I feel dirty. I took a bath but it won't come clean. : (

It just goes to show that you can get used to anything if you do it often enough. Emacs still drives me up the wall but maybe I've achieved a critical mass of enough custom keybindings to let me tolerate it.

Aside from paredit, which has no equal even in Vim, Emacs does have some vaguely non-sucky features. hi-lock is pretty nice (Vim has an equivalent of course). Once I learned a few of the shortcuts for git-emacs I actually found myself using Git much more effectively. Having to drop into a shell to type Git commands is just enough of a disruption to prevent me from doing it often enough. I never got the hang of any version control library in Vim.

I'm almost even getting used to the Emacs buffer model. I find myself C-x bing and flipping back and forth between buffers by name, rather than my Vim practice of opening buffers in certain carefully-placed windows and leaving them there.

On the subject of typing, I broke down finally and ordered a Unicomp Customizer 104 keyboard. I've heard too many hackers say that the old IBM clicky keyboards are good for typing. It should arrive Tuesday, and I'm a lot more excited than anyone should be over a keyboard.

Expect a keyboard review. Try to contain your excitement until then. I know it'll be hard.

Disabling Ctrl-Alt-Backspace

Sat, 04 Apr 2009 23:44:41 -0700

After being reminded the hard way yet again that C-S-Backspace in Emacs invokes the very handy kill-whole-line function, but that C-M-Backspace, while uncomfortably similar to that key-chord, does something very different, I have now officially added to my /etc/X11/xorg.conf:

Section "ServerFlags"
    Option "DontZap" "True"
EndSection

to prevent me from accidentally murdering my X server at the worst possible times.

Juvenile?

Wed, 25 Feb 2009 17:27:44 -0800

I get a cheap thrill out of editing my ~/.emacs file in Vim.

Emacs annoyance #448,546

Sun, 12 Oct 2008 15:04:12 -0700

From the Emacs docs:

Each buffer has a default directory which is normally the same as the directory of the file visited in that buffer. When you enter a file name without a directory, the default directory is used. If you specify a directory in a relative fashion, with a name that does not start with a slash, it is interpreted with respect to the default directory. The default directory is kept in the variable default-directory, which has a separate value in every buffer.

The command M-x pwd displays the current buffer's default directory, and the command M-x cd sets it (to a value read using the minibuffer). A buffer's default directory changes only when the cd command is used. A file-visiting buffer's default directory is initialized to the directory of the file it visits. If you create a buffer with C-x b, its default directory is copied from that of the buffer that was current at the time.

This is extremely annoying. Vim leaves my working directory the hell alone, why doesn't Emacs? Vim lets you set a global working directory, and selectively (and explicitly) change it on a per-buffer basis. This is what I want.

But in Emacs, every time you open a file, the working directory automatically changes to the directory of that file. If you have multiple files open in Emacs (which of course you do), every time you move the cursor between windows, or look at a new file in your current window, your working directory just changed out from under you.

So say you open some files. Then you want to start SLIME. So you C-x 2 to split and open a new window, in which to start SLIME. Except (annoyance #448,547) Emacs doesn't open a window with a new BLANK file, as Vim sanely does via CTRL-W n; instead it puts the file you're looking at into BOTH windows, which is absolutely never what you want. As a result, the working directory of BOTH windows is the directory of whatever file you were looking at. So every time you start SLIME, you have to make sure you M-x cd back to the proper working directory first, because otherwise your Lisp process is randomly going to start in the wrong directory.

But you can change the directory of the SLIME buffer after you start SLIME. Just M-x cd or ,cd. Except if you're unlucky enough to be using SLIME for Clojure, which may have set its classpath based on its working directory when you started it. In that case you have to restart SLIME.

But if you kill SLIME, Emacs (annoyance #448,548) jams another random file into the window where SLIME just was. So your working directory just changed again! Or did it? Depends what Emacs decided to put into your window. You may think that, while SLIME is running, M-x cd and/or ,cd and then ,restart-inferior-lisp may do what you want, but you would be wrong; it always reverts back to the original working directory from when SLIME was first started.

Lost? Confused? tl;dr? Welcome to Emacs. So now I'm looking through the encyclopedic tangled mess of Emacs documentation to try to figure out how to get Emacs not to change my working directory, ever, unless I say so. This is hindered as always by (annoyance #448,549) Emacs' arcane and non-standard terminology. So far, I have committed to memory that "current directory"/"working directory" in Emacs is instead called "default directory". And you don't open files, you "visit" them. Command line? No, "minibuffer".

Vim + screen + REPL = win

Sat, 06 Sep 2008 00:36:48 -0700

Via the Clojure wiki I found a great page describing how you can use GNU screen and some Vim magic to let Vim play nicely with an interactive commandline program like a Common Lisp REPL, Ruby's irb, or Python's, well, python.

That page is a very stripped-down and simpler version of what Limp does for Vim+Lisp. But Jonathan Palardy's version has the benefit of being so simple that you can set it up yourself manually in a second or two. I still have never gotten Limp to work quite right and I don't have the time to debug a big mess of Vim script.

The idea is to start up a named screen session via e.g. screen -S foo -t bar, then start an irb session (or whatever) in there, and then in Vim you can simply yank some text into a named register and send it off to screen via a system call. Download Jonathan's code and see.

It's not a full-blown SLIME; it doesn't have tab-completion or weird interactive debugging windows or such bullcrap. It doesn't capture the output of your command and feed it back into your Vim buffer. But hey, it's pretty good for something you can throw together in 2 minutes, and it works.

So there goes my last reason to ever use Emacs. Good riddance, I must say.

Honestly, Emacs just frustrates the living hell out of me. Oh how I tried to like it. I really did. I've used it on and off constantly over the past year. I have Emacs shortcuts written all over the whiteboard in my office. But its braindead window management, its terrible broken undo/redo system, its finger-crippling key-chord combos, its lack of features I need (like line numbering), its reliance on broken 3rd-party elisp hack scripts for things Vim has built in (like line numbering!), its ugly fonts and GUI elements, and so on and so forth. Vim is such a joy in comparison.

Emacs pinky?

Sun, 08 Jun 2008 13:23:44 -0700

I worry about my hands. I play with computers for a living, and part of the reason someone would want to hire me is that I get a job done quickly. And being able to type fast is a necessary (not sufficient) ability for that to happen.

When I was in high school I started getting horrible pain on my wrists and hands. I had to wear a wrist brace for weeks at a time. I don't know what caused it, but too much keyboard time and bad posture and good old repetitive strain injury was and is my best guess. (This was before I'd even heard of Vim. Not sure what text editor I used back then. Probably some Notepad clone, ugh.)

But then I trained myself to type more comfortably, and I haven't had any pain for years. I hold my arms at the proper angle, and I don't bend my wrists or stretch or strain my fingers. My hands bounce over the keys nowadays, on and off the home row constantly. I don't use my pinky fingers to type at all, in fact. When I need to type a q or a number or a tilde, I move my whole hand up and hit it with my ring finger. When I'm vimming, I hit ESC with my middle finger. With practice this is just as fast as keeping your hands on the home row, but I find it far more comfortable. I still do it fast enough that people remark that I'm a fast typist (though I know plenty of people who are faster).

Thus we come to Emacs. Emacs is the king of key chords. I'm OK hitting Ctrl. I pick up my hand and hit Ctrl with the side of my pinky like I'm karate-chopping it with a half-closed fist, or use my pinky and ring finger both. The Alt key I can usually reach with my thumb. But anything that requires Ctrl + Shift or to a lesser degree Alt + Shift is a killer on my hands. I don't know a good way to quickly type Ctrl + Shift + another key in a comfortable way. Caps lock remapped to another Ctrl is the solution many websites list, but that doesn't cut it for me either, it's just pinky-stretching in another direction (and what do you do when you have to hit Ctrl with your right hand?).

For some reason I'm highly amused yet slightly horrified that there really is a condition called Emacs pinky. And that Richard Stallman and other Emacs gurus have famously experienced wrist injuries due to years of using Emacs. How many people in the world can say that their favorite text editor has physically crippled them?

Even if you admit that heavy dependence on the modifier keys is necessary, some of Emacs' keybindings seem ill-chosen to me. See this quote from the Emacs tutorial:

You can use the arrow keys,but it's more efficient to keep your hands in the standard position and use the commands C-p, C-b, C-f, and C-n.

I don't know what kind of creature finds those keys more efficient than the arrow keys or pageup / pagedown, but I don't think it's a human being. (But admittedly, same goes for hjkl in Vim.) Sure, you don't have you move your hands from the home row. You just have to contort them into pretzels. Try hitting up up up down left left right quickly, then try to do the same using those keys.

Same is true of other commands. delete-indentation, which I find myself doing a lot, is M-^. When editing Lisp you may get to experience wonders like C-( and M-J.

Anything multi-chord is also just a little bit torturous for me. How do you execute a command more than once in Emacs? e.g. move down 3 lines? You can either type M-3 C-n, which requires me to hit Alt with my right hand and 3 with my left, then hit Ctrl with my left and n with my right. Or you can do C-u 3 C-n, which actually requires me to alternate hands on the modifier keys three times instead of two. This for something so ridiculously simple as moving the cursor, something I do hundreds of times a day.

This kind of crap leads you to try to hit M-3 or C-u or C-n with one hand instead of two. If I can manage to hit M-3 with my left hand, I can hit the down arrow with my right. M-3 is possible with one hand, but M-8 or M-9 would not be without dislocating a few joints. Down this path leads permanent disability.

Sometimes I toy with the idea of remapping every keybinding or nearly every keybinding in Emacs to something sane. But aside from thoughts such as "Why the heck should it be necessary for me to do this?" or "Why would this possibly be worth my time?", I'm unsure I could come up with anything better. I'd still be limited to using lots and lots of modifier keys. Emacs has had decades of refinement after all, and it's still in this sorry state.

I have tried the Vi and Vim keybindings in Emacs, and they don't work right. They don't work in all buffers, for example a SLIME REPL buffer. Even when Vim mode is working, many of the Vim commands are present, but not all. These huge, massive Emacs-customization hacks always seem to work well maybe 95% of the time for me, but text editor bindings and behaviors are really something you need to work perfectly 100% of the time. Every time Emacs does something ridiculous or one of these third-party scripts mangles my buffer, and I have to kill and reload the file, it completely breaks my stride and throws off my concentration. The text editor needs to get out of your way and let you focus on what you're doing.

Emacs undo is horrible

Sun, 25 May 2008 22:54:34 -0700

Emacs has a, well, "unique" undo system. It only has undo, no redo. When you undo something, the act of undoing is added as itself onto a stack of undo actions. When you've un-done enough things, you do "something, like move the cursor, and that breaks the chain. From there if you undo again, you will traverse back over the undo actions you just did.

This is supposedly powerful. It does help with the following situation:

Type something.
Type something #2.
Type something #3.
Undo undo undo.
Type something #4.

In most programs once you reach step 4, you can redo to get back to the text you just undid But once you reach step 5, the first three things you typed are lost forever. You've gone back in time and changed history, eradicating the old future and replacing it with a new one. You can never get back to the old future. Emacs undo, on the other hand, where undo actions are just like any other actions and pushed onto a stack of actions, does let you undo back first three things you typed.

However in practice this doesn't work so well. This site has a nice quote:

?By [undoing] repeatedly, you can gradually work your way back to a point before your mistake. This is convenient if you?ve made a mistake four or five commands back. It is marginally useful if you?ve made a mistake twenty or thirty characters back. And it is completely useless if your mistake is ancient history.? - Learning GNU Emacs (page 42)

The problem being, supposing you undo 20 times, and break the chain (by moving the cursor for example), if you then decide to undo one step FURTHER back, you have to undo all 20 of your previous undos, undo 20 more times, then undo once more. Eventually you end up feeling like you're going up and down a roller coaster of undos.

If you hate this, which you probably do, you could use redo mode, which gimps up Emacs undo/redo to be like any other program's, i.e. you get the same behavior as Microsoft Notepad. (Although when I tried it, it was buggy as heck, failing to undo my actions properly, mangling text from different lines together and whatnot.)

Vim's undo system on the other hand is far better and equally powerful. You have a standard undo / redo option via u and CTRL-R. You also have a second completely different way to undo: you can "go back in time". In the above example, Vim will create two undo "branches" and you can jump from one to the other even if you undo and "break the chain" by typing something new.

Doing :undol lists the branches, in a somewhat confusing format. But you can just pound g- and g+ to go to older / newer text states, or use :earlier with a human-readable time (say, 10s or 5m) and it will take you to that point. These will get you all the power of Emacs' undo stack, with none of the pain or confusion. See also :h undo-two-ways.

This is one of many instances where Vim wins, hands-down. Vim's undo system isn't as reprogrammable as Emacs, but it's so powerful and so perfectly what you'd want that it doesn't matter. This is beautifully typical of Vim. I don't have a year to figure out all the nooks and crannies and edge cases and idiosyncrasies of Emacs undo system, let alone the time it'd take to write a custom, crusty elisp script to buggily re-implement it.

Being an "extensible text editor" doesn't help much when such basic functionality is so broken. Unless you want to play your undo history back like a movie, in rainbow colors, which I don't. I want undo/redo that works.

Vim joy, Lisp woes

Thu, 15 May 2008 00:17:11 -0700

I symlinked my .vimrc to my local mirror of my website so that every time I rsync it (which is pretty often) it'll automatically update my the vimrc on this server. So that should be fun. I experiment with things in there all the time so at any given moment there are likely to be things horribly broken, but maybe someone can use some of it.

This mirror of Ciaran McCreesh's vimrc which I found linked from here (edit: updated version here) has lots of good stuff in it. In particular using :set listchars to display tabs and trailing whitespace as some funky Unicode characters is a really good idea. When I first tried that good idea I realized my favorite font ProggySquare didn't properly display most Unicode characters, which was part of my motivation to switch to Terminus. (That, and those tiny Proggy fonts aren't so great on a 1920x1200 monitor.)

After a long time putting it off, I finally hunkered down one day and figured out how the heck Vim script works. The difference between statements and expressions in Vim script language confused me for a while, which goes to show that I'm far too used to Ruby and Lisp where almost everything or everything returns a value as an expression. Vim expects expressions in certain places and colon-prefixed commands in others. But then there's normal and eval and execute and "= some of which let you do things from one mode in another mode if you mix and match them. But I think I've gotten a handle on it now.

Today I came across Limp which is a recent attempt to get Lisp to work well with Vim. It seems quite new and buggy and had dependencies on things I had to guess until I was able to install it (like rlwrap), but I still was excited about it. Until I realized that it's just a wrapper around GNU screen. SBCL runs separately, and some keystrokes send stuff from Vim to screen, but that's about it. Nice, but not nearly as nice as SLIME in Emacs. So that disappointed me. In the back of my mind I always think about how Vim could possibly be integrated with Lisp like SLIME does but I don't see any good way. Vim doesn't have the ability to embed shells like Emacs and it doesn't look like it will gain that ability any time soon. Ah well.

Go Emacs go

Tue, 15 Jan 2008 01:17:07 -0800

Ivar Refsdal gave me a great link to a video demonstrating many of the features of SLIME and Emacs. I learned quite a few things from it. I highly recommend it.

I said previously that I wanted something to dim parens in Emacs when I look at lisp code. Enter parenface, which does the job.

Seems like I spend almost as much time setting up Emacs as I do writing code. But the good thing is once I set it up once it'll be set up forever.

Partial Lisp successes

Sun, 13 Jan 2008 02:14:02 -0800

I got my Common Lisp photo blog largely working today. It's nothing special, but it displays thumbnails and photos along with meta-data for them, and it allows navigation to different pages. And it stores objects persistently in a mysql database. I feel like that's an accomplishment given the amount of pain I went through even to get that far. Just getting hunchentoot to serve up static JPG files was a chore I hope not to repeat now that I know how to do it. (p.s.: hunchentoot:handle-static-file) Some features it's still lacking are 1) letting people make comments, 2) anti-spam measures for the comments, 3) letting me post new pictures. Thought it's straightforward enough to do via the REPL, do I really need an HTML form? Probably not.

It's only about 250 lines of code (including all the HTML (or rather the Lisp that generates the HTML) and database schemas), but it could be far shorter and nicer if I knew what I was doing. I've enjoyed playing with Lisp even when it was driving me mad.

I'm not putting the site online yet though, until I have time to take care of such small matters as preventing everyone on the world from connecting and using my REPL, and keeping the server online for more than a few minutes at a time. I know there are ways to keep a Lisp image running and connect to it via SLIME, but I want to read more about it. I also have no clue whether hunchentoot is multi-threaded already or if I need to set something up to handle HTTP requests in parallel or what. I know SBCL supports threading to some degree but I'm unsure how it all works.

And I need to find an Emacs color theme that displays parens in a faded color so they don't stand out so much. I saw a nice one somewhere on someone's blog with a dark background and darkish grey parens but I've since lost it.

I'm better now

Fri, 11 Jan 2008 01:54:15 -0800

I calmed down a bit from yesterday, scrapped all my code and started over, with much better results. I'm not sure what was wrong yesterday, but things work today. I think I may have been using variable names that clashed with function names internal to CL-WHO. Or else I somehow had a CL-WHO macro trying to evaluate function names as variables. Or something. I'm still not sure why it was complaining about PRINC since I didn't mention that symbol in any of my code. But no matter. CL-WHO is properly inherited into my class today; I attribute yesterday to PEBKAC malfunction.

I still have problems with sometimes accidentally obliterating functions that exist in other packages, or functions/variables that exist in my own packages. The problem(?) with a persistent environment is that the effects of one typo live forever, until you clean up your mess. If I define a function and then decide my function needs to be a macro, the compiler complains that I'm murdering a function I defined previously. If I typo a variable name, that symbol is interned whether I like it or not, and it may shadow something important. Peter Seibel mentions this problem in passing at the very end of Chapter 21 of PCL.

Interestingly today, I tried to define an :after method on INITIALIZE-INSTANCE for one of my classes***. I forgot to type the ":after", so I actually obliterated a function that's used as my class's constructor, which is bad because now I couldn't construct objects any more for that class.

I could've shut down and restarted my Lisp image and reloaded all the code (which is what you'd do in any other language: recompile, or re-run the script). But that's overkill and seems like it's very much not the Lisp way to do things.

Instead Common Lisp has facilities to unintern symbols, and undefine functions and methods, and whatnot. This page for example has a snippet telling how to undefine a method:

(let* ((generic-function (symbol-function 'gf-name))
       (method (find-method generic-function
                            '(method-specializers)
                            (list (find-class parameter-class-name)
                                  ; one per argument 
                                  ...))))
  (remove-method generic-function method))

Quoth the website: ...where gf-name is the name of the generic function (i.e. the name of the method), method-specializers is either empty or a method combination specifier, such as :BEFORE, :AFTER, or :AROUND, and parameter-class-name is the name of the class on which a particular method parameter is specialized.

This worked very well. And I actually think I almost understand how/why it works, which is surprising.

I guess some days everything goes wrong, and some days everything goes right. Emacs is mostly behaving itself today; I guess I've managed to chain the beast down enough so that it does my bidding. I managed to define some classes using CLSQL:DEFINE-VIEW-CLASS and now my objects appear in my database as I create and modify them, like magic, which makes me happy. Maybe there's hope yet.

(*** These "method-specifiers" or whatever you call them are an awesome thing in Common Lisp. You can modify the behavior of existing methods by telling CLOS to run a certain method before, after, or around an existing method. One great thing about this is that you can use it to extend the behavior of automatically-generated methods, for example constructors. Say you want to have an object which, after being constructed, is automatically stored in a DB; just define an :after method on the constructor, that takes the already-constructed object and inserts it into the DB. I likes it.)

Emacs windows

Tue, 08 Jan 2008 22:35:00 -0800

I ranted earlier about the horrid window behavior that occurs when using Slime.

Less ranting and more googling reveals that there are some scripts that can make it suck less. Winner mode seems nice for example; it lets you undo and redo window operations like opening/closing/splitting windows.

You can also store window layouts in registers and restore them. So I threw this together:

(defun save-window-layout () (interactive) (window-configuration-to-register ?z))
(defun load-window-layout () (interactive) (jump-to-register ?z))
(global-set-key [C-f1] 'save-window-layout)
(global-set-key [f1]    'load-window-layout)

So C-F1 saves my current layout, and F1 restores it. This is enough to preserve my sanity. I only did those mappings because C-r w z and C-r j z are far too long to type.

Vim vs. Emacs (scripting)

Mon, 07 Jan 2008 20:48:07 -0800

In my ongoing quest to force myself to learn Emacs, I used it today to hack some Ruby scripts.

Vim comes with a Ruby syntax highlighting script, but Emacs doesn't. That's one Emacs annoyance: You have to go fetch Emacs' ruby-mode scripts from somewhere yourself. That's sort of a common thing I'm finding with Emacs. For many things that Vim has built-in or bundled-in, Emacs requires you to go on a treasure hunt.

As another example, I wanted to display line numbers down the left side of my buffer. like seeing line numbers, because it tells me my position in a file at a glance and it shows me wrapped lines easily. And most compilers give errors in terms of line numbers. Vim gives you a black-box built-in solution to this: :set nu.

Emacs on the other hand has no built-in way to do this, that I could find. It has options for displaying the current line number in the modeline, which isn't quite what I want. I had to go looking for 3rd-party scripts to give me my column of line numbers. I found multiple scripts do it, in fact. The first I tried, setnu, seemed to work OK, but after a while it somehow choked and I had read-only line number text splattered throughout one of my buffers. This is clearly not acceptable. Another I found, linum, hasn't died on me yet, but we'll see.

This brings up an interesting point, I think. In the video I talked about before, one question Peter Seibel asks is which you'd rather have, a programming language that has 1,000 built-in functions but doesn't let you define your own, or one that gives you 10 built-in functions but lets you define your own. The answer is probably the one that lets you define your own.

Vim is like the editor with a thousand built-in functions, and Emacs is like the editor that lets you define your own easily. Of course the analogy isn't perfect: Emacs has tons of built-in things, and Vim has Vim-script and remappings etc. to let you customize it. But the point is that Emacs gives you much nicer, lower-level primitives to work with to customize Emacs at a level of granularity that Vim doesn't provide in some cases.

For example, I don't know if there's any way in Vim to make your own read-only column of text down the side of an editable buffer. If Vim didn't have :set nu, could you write it yourself in Vim script? I don't think so, or if so, it surely wouldn't be easy. I'd imagine you'd have to resort to something in C. Vim's built-in :set nu is implemented in C. If I wanted to change how the line numbers look or act in Vim, can I customize it? Only to a certain point: I can customize it only using the options the Vim devs gave me.

Emacs on the other hand gives you accessible, lower-level primitives to work with. So people can and did write their own scripts to implement a column of read-only line numbers; they're written in Elisp. The multiple scripts to do this are different and work in slightly different ways. They're also customizable if I don't like how they work. I don't have to hack into the guts of Emacs to do this; I can do it all in my ~/.emacs.

So I think one area that Emacs totally blows Vim out of the water is in terms of editor customization via scripting. Elisp is leaps and bounds nicer to write than the barftastic mess of crap that is Vim script. Any sufficiently complex Vim script will end up being a tangled heap of evaled strings and mode-switching and gibberish. In Emacs you have a tasty Lisp dialect, powerful and extensible and consistent and regular. And you can do crazy stuff in Emacs like embed shells or Ruby or Lisp interpreters right into the editor, which Vim doesn't let you do.

On the other hand, Vim's :set nu just works, whereas one of the Emacs scripts I tried did not. For a given feature, like displaying line numbers, which would you rather have, a feature written and tested by the Vim devs themselves, or something unofficial that some random hackers (who may be skilled or entirely unskilled) threw together as a 3rd-party extension?

The two cases degenerate into each other. A language or program with so many built-in features that it does EVERYTHING you want is probably just as good as (or in some cases better than) a language or program that lets you define your own ways to do things.

It depends on how much you actually want or need to customize your editor, but I think for my needs, Emacs actually ends up a bit better than Vim in this case. God help me.

Emacs continued; Lisp explorations

Sun, 16 Dec 2007 19:38:19 -0800

Thanks to ruben who posted some helpful comments on how to make Emacs buffer switching better in my latest ramblings. My blog like so many others isn't conducive to posting source code in comments, but I googled up a page about iswitch which provides code for enabling and configuring it. It definitely makes switching between buffers nicer.

I also noticed today that Emacs keeps giving me odd errors ever since I put my Lisp code into a Bazaar repo. Again google to the rescue; turns out Emacs is trying to do some funky crap involving my bzr info. You can turn this off in ~/.emacs via

(setq vc-handled-backends (remq 'Bzr vc-handled-backends))

Another annoying thing about Emacs is how it dumps backup files into directories where you're editing files, so you end up with lost~ of~ screwy~ filenames~ all over your filesystem. You can make it put all backup files into a single directory like so:

(defun make-backup-file-name (file)
  (concat "~/.emacs.d/_backups/" (file-name-nondirectory file) "~"))

To be fair, Vim has the same ugly behavior by default, so to make Vim do the same, you need to put this into ~/.vimrc:

set backupdir=~/.vim/_backups

So yeah, the main reason I'm using Emacs at all is that I'm writing Common Lisp, and if you write Lisp you're almost chained to Emacs. Well, you are if you consider your only options to be Vim and Emacs, which I largely do. I'm too much attached to Vim to want to use anything that isn't largely keyboard-driven.

I'm also using Emacs for bragging rights, of course. How many people can say they're good at Vim AND Emacs? I'll have adoring fans lined up by the hundreds just to watch me write code, in awe and wonder. (Yeah, let me keep believing that.)

My goal as previously stated is to write a photoblog website in Common Lisp. I gave this a good try yesterday. I'm largely handicapped by the fact that I don't know Lisp very well, but I got to the point where it could read a directory tree of photos, categorize them and display them in a browser window. I have a lot of work left, but I'm hopeful I'll get this done. It turns out that things I thought would be hard about this were pretty easy, and things I thought would be easy weren't so much.

One thing I thought would be hard was getting Apache2 to talk to Lisp. Given the absolute nightmare involved in getting Apache to work with Ruby on Rails, I was very worried. But using mod_lisp2 turned out to be extremely easy. I have mod_lisp2 talking to Hunchentoot. Both are in Portage:

emerge mod_lisp2 hunchentoot

Then edit /etc/conf.d/apache2 to add the customary -D LISP to APACHE2_OPTS.

Then find a directory that Apache can see, and add this to .htaccess:

LispServer 127.0.0.1 55555 "hunchentoot"
SetHandler lisp-handler

Replacing the IP and port number if needed. That's all the Apache setup needed. All that's left is to fire up Lisp and start the hunchentoot server from the REPL:

CL-USER> (hunchentoot:start-server :port 55555 :mod-lisp-p t)

And that's it. Now Apache will forward requests to Lisp and render the results. Couldn't be easier.

That just gives you a way for Lisp to serve web pages though; it doesn't give you any kind of framework for building the pages. There's a very interesting series of webcasts involving setting up a web page using Lisp. He uses CL-WHO to produce HTML, which is very similar to the HTML-compiler-interpreter that Peter Seibel goes through in PCL.

So I ended up writing a bunch of code using that library, and a few other helper libraries like CL-FAD to help with pathname manipulation (one area in which Common Lisp is sorely lacking in ease of use, in my opinion). Here's where I started to have difficulties though: loading / requiring libraries in my code. Compile time vs. load time vs. runtime is very blurry in Lisp. Every time I closed Emacs and reopened it and tried to run my file, I'd get all kinds of errors about libraries not being loaded. What I probably need to do is use ASDF to manage all this for me. I must say that even though this is a hassle, it's nowhere near the hassle of trying to resolve dependencies in, say, C++.

Another problem I ran into was that some of my macros were bombing at load time because of functions not being defined soon enough for the macros to use. What I think I need to do there is use EVAL-WHEN as per chapter 21 of PCL.

So yeah, something as simple as loading and running a file full of source code isn't exactly trivial in Common Lisp. For someone like me who's used to writing a Ruby script, and then running the thing from the command line and having Ruby start and load my script and run it and stop, it takes a lot of getting used to a persistent environment like Lisp gives you. But there are also advantages. Being able to fiddle with the guts of your program while it's running is a lot of fun and very powerful if you know how to use it properly, which I largely suspect I don't, but hopefully I'll learn.