Yet another reason not to leave Emacs ... courtesy the console-based CenterIM and a little bit of code in my .emacs file, I can do all my instant messaging (MSN, Google Talk, ICQ, ...) from within Emacs (thanks to Anselm Helbig on comp.emacs for some elisp advice):

I've updated my Emacs setup on GitHub to include the code to set up CenterIM in a multi-term window. You'll want to ensure that your system has CenterIM installed; on Ubuntu this is as simple as:

sudo apt-get install centerim

Note that my Emacs setup is sufficiently clueful to detect if you're running on MS Windows, & not try to start up any multi-term sessions, including CenterIM.

I have deleted The GitHub repositories referred to in this post; see Clearing the deck for details.

I sometimes find myself with the need to close all unmodified buffers in Emacs that pertain to files (not all buffers do pertain to files; e.g. some contain terminal sessions).

I could have done this with M-x kill-some-buffers but this prompts for each buffer; what I wanted was something that would just silently kill any file buffer that didn't have unsaved changes.

So I wrote the following, and added it to my duncans_emacs repo on GitHub.

(defun duncans_emacs:kill-unmodified-buffers()
  "Kill any unmodifier buffers that are inspecting files."
  (interactive)
  (mapcar 
    '(lambda (buf)
      (if (and (buffer-file-name buf) (not (buffer-modified-p buf)))
        (kill-buffer buf)))
    (buffer-list)))

(provide 'kill-unmodified-buffers)

For those unfamiliar with Elisp (the LISP dialect that Emacs is mostly written in):

• mapcar takes a lambda function and a list, then runs the lambda function against each element of the list in turn.
• interactive lets Emacs know that this function can be called by the user using M-x.
• buffer-file-name returns nil if the buffer in question doesn't pertain to a file (for example, a buffer that contains a terminal).
• Elisp doesn't have namespaces, so the function name is prefixed with the package name (duncans_emacs) to avoid collisions.

After finishing this, it dawned on me that LISP isn't what I'd call intuitive or easy to read (although this might improve with time as I'm still a rank LISP beginner). An equivalent script for an (hypothetical) Ruby-based editor might look something like this:

# Kill any unmodifier buffers that are inspecting files.
def kill-unmodified-buffers
  buffer_list.each { |buf|
    buf.kill() if (buf.file? && !buf.modified?)
  }
end

(This is assuming that there's a method by which the parent class can identify user-callable functions). Now I'll concede that LISP has many positive attributes. Terseness and similarity to written English are not two of those, however :-)