Announcing wpmail.el

Hi Planet Emacsen, and thanks Edward!

It was only in June this year that I started to write Emacs Lisp. The first extension I wrote is wpmail.el, which I published on github but didn’t announce as I wasn’t quite happy with it. Since then, I hacked some more on it and it’s in a better shape now, so here’s the obligatory blog post.

From the file header:

An Emacs extension to make posting by e-mail to the blog hosting service easier. It might work with other wordpress installations, which I have not tried. For more information about posting to wordpress by e-mail see the support page

Documentation is a bit lacking, but here’s the gist: start a new post, possibly from the region or the buffer, with wpmail-new-post or wpmail-new-post-here. Send it with wpmail-send-post when you are done. wpmail will prompt for title and category; it will propose some titles that you can see via M-n, and it auto-completes the categories in wpmail-categories. See the documentation of these functions for details.

You can write your posts in Markdown format if you have markdown-mode installed. Set wpmail-markdown-command to your Markdown converter and posts will be converted to HTML when sending them.

I have the feeling that the documentation could be clearer. This is probably due to the fact that while I was writing wpmail.el, my ideas about the best way of using it changed.

Initially, I made it so that the very start of a blog post would be calling wpmail-new-post. It would visit a new file in wpmail-posts-dir and you’d start writing. This requires wpmail to be in charge. Then I realized that it could be less intrusive and added wpmail-new-post-here. It simply turns your current buffer into a blog post by adding a title and the wordpress shortcode directives like “status draft”. Otherwise, it’s up to you what to do with the buffer.

It works pretty well for me now, so I’m not gonna change it around again for myself anytime soon. I’d be happy about suggestions, though!

In the latest version, I also managed to get around two wordpress bugs. One was that <pre><code>, Markdown’s default markup for verbatim blocks, was being garbled.’s support was very helpful and the problem is now fixed. The other is that I remove single line breaks before sending, because while wordpress mostly ignores them (as you should in HTML), it seems to turn some into <br/>.

I hope it’s useful for someone. Let me know if that’s the case!

Announcing md-readme

You can find quite a few Emacs libraries on github these days. I only have one very small project there, wpmail, which I haven’t written about yet because I want to finish the Markdown support first… anyway: something I find really neat on github is the automatic display of the README file in the repository’s root directory, if it exists. Only, as we all know, writing READMEs is tedious and we’d rather spend our time programming. But wait: in the Emacs world, we’re actually writing a README for each project: the library headers. Their content and structure are rather clearly defined, and it’s expected for all Emacs libraries. So I had the idea of generating a nice, Markdown-formatted for github from these headers.

I just pushed the first version of md-readme that does just that. The README that you see on the github page is auto-generated from md-readme.el, with lists, code-block and everything.

The conversion to Markdown is of course pretty simple, but even so it’s pretty cool to see how little code I had to write. Emacs provides everything out of the box. (with-temp-file "" (do-it)) is just elegant.

Now, seeing that we have code that generates a nice README from our Lisp file, it’s natural to have it run automatically so we always have an up-to-date README. Here I was struggling for a while. I had lots of ideas, but none seemed to work out. My current solution is setting a per-directory local variable for each of your ELisp projects that triggers the conversion via an after-save-hook. Code is in the README. The problem with adding the after-save-hook to all modes is that it’s evaluated all the time, for each save. Kinda annoying, even if it’s just a single condition.

Does anyone have a better idea? Do it outside Emacs in a git pre-commit hook?

But even with the current solution it works, and that’s the important part. Please try it, and enjoy your new READMEs.

CouchDB and your life

I just watched a moving talk, Damien Katz‘s CouchDB and Me. It’s about Erlang and financial security, family and distributed databases, being a good programmer and being unemployed, dreams and bureaucrats at IBM.

At the Rubyfringe conference, Katz gave a personal account about how CouchDB came to be. Programming and some technical aspects naturally play a role, but he mainly talks about the personal decisions he had to make. Giving up your steady income and social position to write cool open source software – why would you do that? He did it and made it from feeling like an unemployed loser to being paid to work on his project, on his own terms, by IBM. He comes across as being really open about his experiences and his decisions, and I certainly took away a couple interesting insights. Find out what interests you and just start doing it, learning what you need. It’s ok to be driven by the idea of having an interesting story to tell; after all, the story of your life will be what you did and experienced. These are just two out of many things that stuck.

I came across this talk reading a discussion on HN. Like Katz’s talk, it’s kinda about programming, but really about life. Life as a programmer, maybe; but maybe about everyone. It makes me happy to see these discussions. I’m into programming not because I want to live in a cold world of machines, but because computers challenge your mind, because you can create something with them, even on your own, and maybe even make a living out of it. It’s about you in the end, not about the machine.

Now focus!

I’m having fun with this bit of Emacs Lisp that turns your current buffer in a fullscreen, minimal, no-frills frame a la Writeroom. I got it from the EmacsWiki and made a few small modifications.

Now, whenever you feel distracted, tell your Emacs (and thus yourself, as Emacs is a direct extension of your brain): now-focus!.

(defun now-focus! ()
  "Open the current buffer in a frame without any bling."
  ;; to restore:
  ;; (setq mode-line-format (default-value 'mode-line-format))
  (let ((frame (nowfocus-make-minimal-frame)))
    (select-frame frame)
    (setq mode-line-format nil)
    ;; for Windows, untested
    (when (fboundp 'w32-send-sys-command)
      (w32-send-sys-command 61488 frame))))

(defun nowfocus-make-minimal-frame ()
  (make-frame '((minibuffer . nil)
		(vertical-scroll-bars . nil)
		(left-fringe . 0)
		(right-fringe . 0)
		(border-width . 0)
		(internal-border-width . 64) ; whitespace!
		(cursor-type . box)
		(menu-bar-lines . 0)
		(tool-bar-lines . 0)
		(fullscreen . fullboth)
		(unsplittable . t))))

If you’d like some more options, turn to darkroom-mode.

Testing Wicket ListViews using IVisitor

The standard solution for unit testing Wicket apps is WicketTester. It works fine, but doesn’t offer much for testing ListViews. The assertListView method lets you test the contents of the ListView, but not the UI.

You can always extract the ListView rows into a Panel, of course. But when you don’t want to do that for whatever reason, it’s simple to side-step WicketTester and do the necessary tests yourself, especially since rows that are not in a panel of their own should be pretty simple.

An approach that works well for me is visiting the ListItems using MarkupContainer.visitChildren() and then accessing their components via Component.get(). To focus on the essential part, I’m using a method listView() in my example that gets the ListView from the rendered page. Once we have it, we visit its items.

listView().visitChildren(ListItem.class, new IVisitor<ListItem>()
	public Object component(ListItem item)
		Component uri = item.get("uri");
		// etc.
		// If testing one row is enough, we can stop here.
		return IVisitor.STOP_TRAVERSAL;

Once you see it, it’s trivial. WicketTester’s assertComponent() isn’t magic, you can do the same in three lines: get the Component via its path, assert it’s actually present, and assert it’s the right type.

If you want to do further tests on the component’s internals, I find it practical to expose those through package-scoped methods, provided your tests are in the same package than your app.

Finally, something that bit me once: how ListItems work with the list model. Say we have this (just a rough sketch):

class Foo
	List bars;
	List<Bar> getBars() { return bars; }

// On some page, the model is a CompoundPropertyModel&lt;Foo&gt;.
add(new ListView<Bar>("bars")
	protected void populateItem(final ListItem<Bar> item)
		item.add(new WebMarkupContainer("id"));

If you get hold of the WebMarkupContainer(“id”), for instance using an IVisitor like I showed above, and you call getDefaultModelObject() on it, what do you get? One might expect a Bar; after all, it’s a ListView<Bar>. Not so – you get a Foo.

ListViews work on the original List instead of a copy. Each ListItem is backed by a ListItemModel, which knows the index of the element it represents, but has no model itself. When the model is looked up, the normal Wicket model chaining happens, so we get to the CompoundPropertyModel. The ListView code of course knows about this and uses the ListItemModel’s index to get the right Bar from the list. But getDefaultModelObject() doesn’t know about this and simply returns the Foo.

If you are in that situation, explicitly ask for the ListItemModel:

((ListItemModel) component.getDefaultModel()).getObject()

should give you a Bar. Of course, if you visit the ListItem itself like in the example above instead of a nested component, you can just call getObject() on it and it does the right thing.