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."
  (interactive)
  (my-initialize-frame 3))

(defun my-small-screen ()
  "Set up frame for laptop screen, with two windows."
  (interactive)
  (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)
  (delete-other-windows)
  (dotimes (not-used (1- columns))
    (split-window-horizontally))
  (balance-windows))

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).

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.

Andy starts by noting that Guile is different things to different people:

• A GNU language, with bindings for many components of the GNU system and under LGPL 3.
• A Scheme implementation, supporting R5RS and part of R6RS, plus other goodies: modules (not the R6RS ones), hygienic macros, the CLOS-like object system Goops with transparent integration with GLib’s gobject, Posix interface, and Unicode support.
• An extension language for applications, like the Gimp.
• A part of the GNU system (that we are making, even if we don’t know yet how it will look like).

Andy sees Guile’s perception among developers as its main challenge currently. It’s seen as being slow, although it’s generally faster than Python. But there are also opportunities for its perception: its multilingual vision and support–its next release will support ECMAScript besides Scheme, and Emacs Lisp is coming–, and the GNU brand.

Some technical notes

It uses the Boehm-Weiser garbage collector now, which is fast and reliable.

There are ten committers and monthly releases. This is after the project emerged from a long drought in 2000-2007.

Guile has a VM, and a native compiler is coming. Also: JavaScript support, ELisp coming!

It has really good Emacs integration now with Geiser.

There was also a small remark about licensing. Readline and Guile are not quite license-compatible, which makes using the REPL a pain. This sparked a longish discussion–kinda what you expect from a GNU developers meeting :-)

Spreading the Emacs nature

And now, the meat of the talk: spreading the Emacs nature, to emacsify the GNU system. Yes, that sounds like it!

The upcoming Guile 2.0 (or maybe 2.1?) will have full ELisp support, at the moment about equally fast than Emacs’ own, but it will be much faster. It will also have native compilation for even more performance.

Besides performance, it will have much more to offer:

• native threads,
• a clear FFI,
• modules,
• other languages, as described above,
• the Goops object system,
• lots of library bindings – Emacs-Gnome integration would easily be possible, for instance.

Andy’s plan is to replace Emacs’ Lisp engine with Guile. The rest stays unchanged, existing ELisp code will run as-is. Then no form of coercion should be necessary to get people to start writing their Emacs code in Guile languages. The timeframe is 18-30 months from now–looks like a developer release is not too far off!

Conrad Barski’s awesome Lisp tutorial Casting SPELs is now also available in an Emacs Lisp version, edited by James Webb. Even if Emacs Lisp is certainly not the greatest Lisp dialect, it shouldn’t matter much for a beginner’s tutorial and it sure is nice to be able to evaluate everything right in your editor.

ars technica: Tentacular, tentacular!

Cthulhu plucked a manila folder from somewhere within the non-Euclidean geometry of his manbag and dropped it on my desk with a thud.

A geeky, hilarious choose-your-own-adventure story written by Cthulhu. What else could you want for your Easter weekend.

Alas, all my previous attempts at journaling failed. Whatever the reason, whether on paper or on the computer, I never felt entirely at home with the solutions I tried. So what’s a hacker to do – write his own solution.

I know that there are already many ways to write a journal in Emacs. Well, here’s another one: simple-journal. It’s tiny and simple, it produces a Markdown format that I love, and having it written myself I feel more inclined to actually use it.

The journal looks like this:

### 2010-01-10

- **18:15** - "XML serializations should be hidden away from
  human view lest small children accidentally see them and become
  frightened." - from the paper *Representing disjunction and
  quantifiers in RDF*, McDermottDou02.pdf.

### 2010-01-17

- **14:45** - Set up a minimal Wicket application with Netbeans (a
  first for me, version 6.8) and Jetty. I want to try out working
  asynchronously with JSON using Wicket. Here are the steps to get the
  application running, serving up an empty page:

  - Start a plain Java SE project in Netbeans.
  - ... 

Being in Markdown, it’s very readable, and can readily be converted to well-formatted HTML. The format is completely hard-coded in the code for the moment. The goal was just to quickly get something simple and small working. Nevertheless, I’m always happy about feedback and ideas.

There’s one item on the TODO list that I’d really like to have, but I’m wondering about how to implement it a somewhat simple and efficient way: showing all entries that have “TODO” in them, or that start with “TODO”. Do I have to go through the buffer to collect them and show them in a temporary buffer? That would be a bit more programming than I feel is appropriate for such a task, and the temp buffer wouldn’t be in sync with the journal. Planet Emacs, ideas? ;-)

Now, in case that’s not nerdy enough for you, I found a version in texinfo yesterday. Complete with all graphics converted to ASCII art. Yes, kinda scary, but it rocks: have your Emacs display an info buffer with the book and a Scheme or CL REPL to play with the book’s code and work on the exercises. Just move around the book and evaluate the code snippets there. Neat!

I guess that means I have to resume my project of working through the exercises. I’m not even sure where my first couple solutions are…

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 wordpress.com blog hosting service
http://www.wordpress.com
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
http://support.wordpress.com/post-by-email/
.

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
http://daringfireball.net/projects/markdown/
if you have markdown-mode
http://jblevins.org/projects/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. WordPress.com’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!

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 "README.md" (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, 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."
  (interactive)
  ;; 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.