Irreal

As many of you know, I live happily in the Apple Ecosystem but do virtually everything that doesn’t involve the browser in Emacs. One exception is my calendar. Events like “Renew ACM membership” or “Research ways of doing \(X\)” are added to my todo.org file and appear in my Org Agenda. Events with a specific, hard date and time attached, such as a doctors appointment, are added to my Apple calendar.

That’s a bit schizophrenic, of course, but it works well for me. The advantage of using the Calendar app is that the event and details about it are synched to my other Apple devices—including my iPhone—and so go with me everywhere. It’s possible, certainly, to use an app like beorg or organice to get my Org-mode events synched to my iPhone but as I said, this system works well for me.

A potential problem with maintaining one’s calendar in Org-mode is alerts. The Calendar app will alert you to upcoming events even when you’re not in Emacs. It wouldn’t do to miss an alert from Emacs because you happen to be, say, in the browser. Christian Tietze has in interesting post in which he explores the beginning of a solution to the problem of having Emacs generate MacOS native alerts. It turns out to be pretty easy although there are some edge cases. Those seem reasonably easy to fix so if you’re interested in that type of functionality, be sure to take a look at Tietze’s post.

There are other possibilities. One is to use Growl. It’s a notification system that can receive messages from other applications and show them on a system wide basis. There is, of course, an Emacs interface. Or two. Another possibility is John Wiegley’s alert module, which he describes as a Growl workalike. Doubtlessly these systems would require a bit of integration but since I’m satisfied with my hybrid solution, I haven’t looked into what would be involved.

A couple of days ago, I wrote about the minor controversy concerning the names of the Lisp functions car and cdr. Some people, mostly non-Lispers but also some who use Lisp, dislike the names and think they should be changed to something more mnemonic like head and tail or first and last. Paul Graham disagrees and tweeted an excellent, pithy argument as to why. I agreed with Graham and the post was really about his tweet.

Of course, being Lisp, it’s easy to alias the names to whatever you like. However, there is, at least for Emacs, a practical reason that you shouldn’t do that or at least that you should know what you’re doing before you try. Chris Wellons, who has a profound understanding of Emacs and Emacs Lisp has a very enlightening post as to why adding something like

(defalias 'head #'car)

to your init.el file is a bad idea. The reason for that is that Emacs Lisp recognizes the importance of car and cdr and has special byte code operators for them. When you alias car to something like head, the optimizer can no longer be sure that the meaning won’t change and therefore turns the head reference into a function call. Wellons has the details but the TL;DR is that the result runs twice as slowly.

This is Emacs so it is, of course, possible to do the alias and still have the result use the car byte code but you have to tell the optimizer explicitly to do so. Again, see Wellons’ post for the details.

Wellons’ post is a slight expansion of his comment to the reddit post asking how to alias car that I referenced in my original post. His explanation is generally useful, though, so I’m glad he made it a separate post.