Irreal

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.

I was browsing Magnar Sveen’s excellent What the .emacs.d!? blog and came across a post on elisp-slime-nav-mode, a mode that brings a bit of Slime-like navigation to Elisp. It’s not part of the Emacs distribution and Sveen didn’t say where it comes from (it’s available on MELPA) but after a little investigation I discovered that it was written by Steve Purcell. That lead me to Purcell’s emacs.d repository on Git Hub. What a find! Purcell has a ton of really good ideas and code. Doubtless I’ll be discussing some of them later but today I want to talk about zap-to-char.

Everyone agrees that zap-to-char is really useful but at least half the commentary about it complains that it zaps up to and including the specified character. Much more useful, these complaints say, would be to zap up to but not including the character. It turns out that the stock Emacs distribution does include a function that does just that: zap-up-to-char. The problem is that it’s in misc.el, which is not loaded by default, and does not have an autoload associated with it.

Purcell fixes that by simply providing an autoload and then binding zap-up-to-char to 【Meta+z】 and zap-to-char to 【Meta+Z】 on the grounds that zap-up-to-char is more useful and should have the easier key sequence. I’m used to having 【Meta+z】 be zap-to-char so I did it the other away around:

(autoload 'zap-up-to-char "misc"
  "Kill up to, but not including ARGth occurrence of CHAR.")
(global-set-key (kbd "M-Z") 'zap-up-to-char)

Now you can have the best of both worlds. Be sure to check Purcell’s repository out. It’s full of great tips and tricks.