Posts Tagged ‘elisp’

Simple Frame Initialization


Is anyone else confused by the variety and complexity of packages for Emacs session management out there? I read through some of the documentation recently, but in the end I was overwhelmed and didn’t install anything.

Session management is about open files, buffer positions and the like on the one hand, and about the frame configuration on the other hand. I realized that my actual use case for frame session management was so simple that I could trivially implement it myself.

All I really wanted was that my Emacs would launch in fullscreen, and split it into two or three vertical windows, depending on whether I was using the laptop screen or the larger external screen. If I could accept the two-split as default, and run a function to create the three-window setup when needed, then all I’d need were some small initialization functions.

Like almost everything else, Emacs exposes its window and frame handling in an ELisp API. So here we go:

(defun my-big-screen ()
  "Set up frame for external screen, with three windows."
  (my-initialize-frame 3))

(defun my-small-screen ()
  "Set up frame for laptop screen, with two windows."
  (my-initialize-frame 2))

(defun my-initialize-frame (columns)
  "Set current frame to fullscreen and split it into COLUMNS
vertical windows."
  (set-frame-parameter nil :fullscreen t)
  (dotimes (not-used (1- columns))

This is not rocket science and I hope it didn’t bore the Planet Emacsen readers, but maybe it encourages people to get creative with their Emacs’ frames and windows. Start with the Emacs Lisp manual, chapters 28 (Windows) and 29 (Frames).


Announcing delim-kill.el


A few weeks ago, I had the chance to attend a few courses on Perl and one on giving technical presentations, held by Perl guru and uber-geek Damien Conway. They were fantastic—just like the ones last year—so I should really write a post of its own about them. Strongly recommended.

But for now, this is about one particular thing he said about editing: you need to have a shortcut in your editor that cuts or copies the text between two given characters around cursor, or point in Emacs lingo. This lets you do many frequent editing tasks easily. Say you’re going through a source file and want to move {}-delimited blocks around, or copy the field you’re on in a CSV file, or the current section in a Markdown file (from # to the next #, roughly).

Damian showed this off in Vim. I knew right away that I wanted it in Emacs. There are of course specialized functions for doing things with certain groups of delimiters, such as the ubiquitous sexp-based functions in Emacs, described extensively on the EmacsWiki. But these rely on pre-configured groups of delimiters, and to kill the text, you have to do one extra operation. I liked the idea of having a single function, and thus key binding, to do all of it. And most importantly, it seemed an interesting challenge for my still-developing Emacs and Lisp skills, so I didn’t even do a lot of research before I dug right in and wrote delim-kill.el.

delim-kill.el contains a single convenience function for editing structured data: delim-kill. Given two characters FROM and TO, delim-kill kills the text between the first occurrence of FROM before point and the first occurrence of TO after point. FROM and TO may be identical.

If FROM and TO are not identical, the function preserves the balance between the two characters: For each FROM that is encountered while looking for TO, one additional TO is required; and vice versa. For example, in “{ foo X{bar} baz }”, with X being point and “{” and “}” as delimiters, the text “{ foo {bar} baz }” will be killed, not “{ foo {bar}”.

I had fun writing this. It turned out to be a bit harder than I expected, mainly due to all the corner cases like point being on one of the delimiters—like most programming, really. I wrote plenty of unit tests to be sure to handle these cases. It’s very little code now, but when I first had a working version, it was twice as big. Once I had it working, I could see lots of symmetry between the different cases that I could extract into shared code.

Also, I finally learned the condition-case error handling of Emacs. And being able to pass functions as arguments is just great, coming from my mostly-Java day job.

Try it out if it sounds useful to you, and let me know what you think.

Slightly edited 2010-05-16.

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.

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.