Irreal

Yesterday I posted a reminder about Yoo Box’s excellent article on lexical binding in Emacs 24. I recently came across a post by Sergey M over at On elisp and programming in general that also considers lexical scoping in Emacs 24. This post has additional information from that given by Box so it is also worth a look if you’re trying to figure out how lexical binding works and what it can do for you.

Back in January, I wrote a short post recommending Yoo Box’s piece on lexical scoping in Emacs 24. Now that Emacs 24 is officially released, this seems like a good time to remind folks about Box’s post. If the idea of lexical scoping is new to you this is an excellent introduction to its use in Elisp. Recommended (again).

I have two machines on which I do most of my writing and development: a 27″ iMac and a 5 year old MacBook Pro. I use both of these computers everyday so I need to keep them in sync. I do that with Git repositories that live on a separate Linux server. One of those repositories contains all my org files. That includes blog posts, todo and task lists from my org agenda, and various other files that I maintain with org-mode. Those, along with all the other archived files means that I have a lot of files to keep up to date.

The first thing I do when I begin a session is a git pull to make sure I have the latest files from the other machine. Of course that means I have to be religious about pushing any changes to Git but that’s pretty much second nature now. The other thing you need to know is that when I’m finished with a session, I just put the machine in sleep mode. That means my Emacs still has all the open files from the last session when I get back to it. I also have desktop-save-mode on so this happens even if I turn the computer off or reboot it.

Here’s the problem. After the Git pull, those buffers and their underlying files are no longer in sync. I could set Emacs to automatically sync them but I don’t want to deal with the overhead. Thus I have to run revert-buffer by hand for each of the updated files. That’s a pain, of course, and cries out for automation so I wrote a quick bit of Elisp to do it for me. Here’s the code

(defun revert-all-buffers ()
  "Revert all non-modified buffers associated with a file.
This is to update existing buffers after a Git pull of their underlying files."
  (interactive)
  (save-current-buffer
    (mapc (lambda (b)
            (set-buffer b)
            (unless (or (null (buffer-file-name)) (buffer-modified-p))
              (revert-buffer t t)
              (message "Reverted %s\n" (buffer-file-name))))
          (buffer-list))))

The code is pretty simple. It goes through the buffer list looking for buffers with an underlying file. If the buffer is not dirty, I call revert-buffer to get the changes from the Git pull into the buffer. If I’ve made changes to the buffer, then I have to fix things up by hand so I don’t want to do the revert.

It seems to me that there’s nothing special about my work flow so others may have the same problem and find revert-all-buffers useful.

The other day I was griping to Xah Lee off-line about the refusal of the Emacs maintainers to add the CL package functionality to the core Elisp distribution. Lee pointed me at several threads on the emacs-devel mailing list that explained both sides of the controversy. Now Lee has summarized those threads for the benefit of anyone else who may be interested.

My own opinions are somewhere in between the two extremes. I have no particular desire to make Elisp into Common Lisp so I tend to think of the CL package as adding useful functions to Elisp rather than making Elisp into CL, which the package certainly doesn’t do. Some folks, like RMS, may find CL ugly and they’re entitled to that opinion but why should that be an excuse to exclude things like incf, reduce, and remove-if-not useful functions that get implemented (for various values of implemented) by every Elisp user who makes the decision not to add

(require 'cl)

to their programs.

Other excuses, such as “it would make the Emacs manual too large” are non-starters. It would make the manual too large. Really? That’s your reason for not including the CL functions in core Elisp? Sorry but if you say stuff like that don’t expect people to take you seriously even if you are RMS.

Others have noted the plans to replace the Elisp engine with Guile (Scheme) but those plans actually call for using the Guile engine with its Elisp language layer not for replacing Elisp with Scheme so I don’t see how that fact enters the argument at all. You still need some sort of reduce function when writing in Elisp whether the underlying engine is the traditional Emacs one or Guile.

Sadly, this question has devolved into a religious argument so we can expect no resolution in any time span meaningful to human beings. Still, it would be nice if we could just add those functions that almost everyone agrees are useful and not mention Common Lisp at all. Can’t we just pretend we found them lying on the side of the road?