Irreal

In my Two From Phil post I mentioned that Phil had urged me to try winner-mode and that I was going to give it a try. For those who came in late, winner-mode captures the current window configuration and allows you to restore it after it gets changed by some Emacs action.

I was a little skeptical but I enabled winner-mode and 10 minutes later I was hopelessly addicted. This all comes at a good time because I have lately been setting Emacs to be 162 characters wide so that I can have two columns of “standard sized” windows¹. That set up makes it really easy to mess up your window configuration. For example, if you bring up a help screen, the focus remains in the original window as usual but now it’s hard to get rid of the *Help* window. If you type 【Ctrl+x 1】 you blow away all your other windows. You can switch into the *Help* window and type 【q】 but that’s a pain. With winner-mode you simply restore the previous window configuration and you’re back to where you were before invoking help.

If you aren’t currently using winner-mode, do yourself a favor and give it a spin. It’s built-in functionality so all you have to do to try it is type 【Meta+x】 winner-mode and you’re all set. Now 【Ctrl+c ←】 will restore the previous window configuration and 【Ctrl+c →】 will redo the configuration you just destroyed.

Try it like this for a bit and see if you aren’t addicted too. If you are, just add

(winner-mode 1)

to your .emacs or init.el file and it will always be their for you. If you don’t like it, just turn it off with 【Meta+-1 Meta+x】 winner-mode. I had intended to try it for a week or so to see how I liked it but, as I say, I enabled it permanently almost immediately. Really, you should try it out.

Regular reader and commenter Phil has made a couple of good observations in the comments of recent posts that I think are worth bringing to everyone’s attention. Since not everyone follows the comments, I decided to mention them in a separate post.

In the Naming Registers post, Phil mentions winner-mode and says that you’re really missing out if you don’t use it. When I replied that I had never understood the point of winner-mode, he explained further why it’s so useful. The basic idea is that it’s like Magnar Sveen’s Magit hack to restore your window configuration after quitting Magit but it works anyplace. I’m going to give it a try and will probably write up my impressions later.

In response to my More isearch Goodness post, Phil mentions that you can get extensive help—including all the available bindings—by typing 【Ctrl+h Ctrl+h】 while in isearch. That’s handy if you forget a key sequence or just to see what’s available.

Thanks to Phil for a couple of handy tips.

As regular Irreal readers know, I prepare all my blog posts with org2blog. One of the nice features of that is that any code I include in a post is automatically fontified in a language appropriate way. Recently, both Xah Lee and Magnar Sveen have published short pieces on how they include source code in their blog posts. They both use a strategy of calling htmlize to do the heavy lifting of fontifying the code.

Sveen’s method is specialized for his What the .emacs.d!? blog. He calls htmlize-region to mark up the selected code with appropriate <span> tags for use with CSS. The result is inserted into a template for the blog post and written to a buffer associated with a file for that post. It’s simple, direct, and purpose-built for writing What the .emacs.d!? blog posts. He can mark some code from his configuration files, call what-the-emacsd-post to htmlize it and insert the result into a post template ready to be completed and published.

Lee’s solution is more comprehensive. He writes about many languages so his strategy is different. With his code you put the cursor between the <pre> tags for code you want to include and call htmlize-pre-block. The language of the source code is extracted from the <pre> tag and then the code in the pre block is inserted into a temporary buffer that is set to the appropriate mode according to the language extracted from the <pre> tag. Next htmlize-buffer is called to mark up the code and the result replaces the original code between the <pre> tags.

This is a nice solution because it can handle a large range of languages and is reasonably flexible. Notice that Lee’s method assumes you already have the code in a pre block and that you just want to fontify it. In a sense, it’s the reverse of what Sveen does: extract the code from a source file and insert it into a new HTML file.

Both of these solutions are useful. Which one you should use depends on your work flow and whether you are dealing with one language or many. For my part, I have always written my posts in Org mode. Before I started using WordPress and org2blog, I wrote my posts in Org mode and called

(defun blog-post ()
  "Export an org buffer as HTML but only export the body."
  (interactive)
  (org-export-as-html 3 nil nil "*blog-post*" t))

to turn the whole buffer into HTML. Then I pasted that into the Blogger control panel to publish the post. A little clunky but much better than typing in posts to the control panel.

I like to see how other bloggers handle the writing and publishing of their posts so I always enjoy posts like Lee’s and Sveen’s. Besides, it’s always nice to see Emacs in action.

In A Nice Emacs Trick, I wrote about how you can enter query-replace or query-replace-regexp directly from isearch and use the isearch search string as the FROM parameter to query-replace or query-replace-regexp. It turns out that there’s a lot more isearch goodness available.

Steve Purcell, who I first talked about in Zap Up To A Character, has a nice collection of isearch enhancements. One of these merely drew my attention to functionality that’s already there but hardly anyone knows about: you can call occur directly from isearch using the search string for the input to occur by calling isearch-occur. That’s bound to 【Meta+s o】 by default but Purcell binds it to the easier 【Ctrl+o】:

(define-key isearch-mode-map (kbd "C-o") 'isearch-occur)

Another common use case is wanting to end the isearch on the other side of the match. For example, if you are searching forward but want to put point before the match instead of after it you have to do something special to get it there. With a single word for the match,【Meta+b】 does the trick but more complicated matches (multiple words, say) aren’t as easy. Purcell provides isearch-exit-other-end to do this and binds it to the very sensible【Ctrl+Return】:

(define-key isearch-mode-map [(control return)] 'isearch-exit-other-end)

I’ve already added both of these to my init.el.

There are a couple of other enhancements in Purcell’s init-isearch.el file so be sure to head over and take a look. Perhaps you’ll want to add some of the others.

Over at Zmalltalker, Marius Mårnes Mathiesen has a very nice post on the mu4e email app for Emacs. Mathiesen, who’s used many different email programs says that mu4e is the first one that he’s ever been happy with. To the question, “Should I start using it?” he answers, “If you use email, the answer is yes.”

The post is a good introduction to mu4e and gives you an idea of how it works and what its interface looks like. The other two links above are to the Emacs-Fu posts about mu4e. If you’re dissatisfied with your current mail app (or even if you aren’t) you should definitely take a look at these posts. Mu4e may be just what you’re looking for.