Irreal

The indefatigable Sacha Chua volunteered to edit the videos of the recent Emacs Conference and I’ve been looking forward to watching them. The problem was that I haven’t been able to find a list of those ready for viewing. Until now. I stumbled across this play list on the emacs-reddit which has the videos for the talks by

• Joakim Verona
• Nic Ferrier
• Joe Corneli
• Sam Aaron
• Dimitri Fontaine

Presumably Chua will add others as she completes them.

This is a tremendous resource for those of us who couldn’t attend in person. We all owe Sacha Chua a huge thank you. Head on over to her blog and say hi and leave a note of thanks. You might also want to check out her sketch notes of the talks.

It’s been a while since we’ve had a EmacsGolf challenge but I just ran across this post from Cameron Saul with the perfect problem for us. Here’s the problem: Saul is writing some Java code that looks like this

TextView textViewRoute = (TextView)convertView.findViewById(R.id.textViewRoute);
TextView textViewDirection = (TextView)convertView.findViewById(R.id.textViewDirection);
TextView textViewStartStop = (TextView)convertView.findViewById(R.id.textViewStartStop);
TextView textViewStartDist = (TextView)convertView.findViewById(R.id.textViewStartDist);
TextView textViewStartPrediction = (TextView)convertView.findViewById(R.id.textViewStartPrediction);
TextView textViewEndStop = (TextView)convertView.findViewById(R.id.textViewEndStop);
TextView textViewEndDist = (TextView)convertView.findViewById(R.id.textViewEndDist);
TextView textViewEndPrediction = (TextView)convertView.findViewById(R.id.textViewEndPrediction);

Notice that each line is the same except for a single symbol that is repeated twice. Saul says he wouldn’t have to write all this boilerplate if he were writing in a language that didn’t hate fun. My first thought was, “or if you had a decent editor.” So our job is to show Saul how to leverage Emacs to make this a trivial problem. You’ll appreciate the challenge more when you see his solution.

Update: Fuco points out that I didn’t specify a starting buffer. Let’s assume that the buffer is empty to begin with.

James Bennett over at The B-List has an interesting post on editors and why, no matter what you finally decide, you should learn either Vi(m) or Emacs. He begins by noting that every couple of years there is a wave of enthusiasm for the newest greatest editor. In previous years it was TextMate, now it’s Sublime Text. But, he notes, there’s a lot to be said for investing in tools that will grow with you through the years. He makes a couple of points worth considering

• Often the new and popular editors will boast of capabilities that are already present in Emacs or Vim.
• Very often, the new and exciting tool will run out of gas resulting in the periodic enthusiasm for a new editor. He cites TextMate as an example of this. Doubtless, the faithful will take exception to this but he has a point that TextMate has pretty much lost its momentum.

All this is especially true of Emacs, I think, because the individual user can adapt it for whatever behavior is needed. If those needs change, it’s simple to adjust the behavior to the reflect current needs. As Bennett says, good tools grow with you.

Bennett’s point is not that you should use Emacs or Vim (although he probably thinks you should) but that you should be aware of the “old,” reliable, and proven editors and what they have to offer. That’s something we can all agree on.

I learned something new from Magnar Sveen’s excellent Emacs Rocks! episode on Paredit: the paredit-convolute-sexp command (bound to【Meta+?】). It’s hard to describe exactly what it does so check out the video to see it in action. The thing is, I didn’t even know that command existed; it wasn’t on my Paredit Reference Card. I noticed some of the other commands were missing too so I decided to find out exactly what commands were available and make a list of them.

I brought up the paredit.el file and started looking around and noticed there’s an odd list of commands complete with examples built right into the code. Here’s the first few entries:

(progn (setq paredit-commands
 `(
   "Basic Insertion Commands"
   ("("         paredit-open-round
                ("(a b |c d)"
                 "(a b (|) c d)")
                ("(foo \"bar |baz\" quux)"
                 "(foo \"bar (|baz\" quux)"))
   (")"         paredit-close-round
                ("(a b |c   )" "(a b c)|")
                ("; Hello,| world!"
                 "; Hello,)| world!"))
   ("M-)"       paredit-close-round-and-newline
                ("(defun f (x|  ))"
                 "(defun f (x)\n  |)")
                ("; (Foo.|"
                 "; (Foo.)|"))
...)))

I thought, “This is perfect. I can use this list to programmatically build a reference card and it will always be up to date.” So I started mapping out the Lisp code in my head but then I remembered this is Emacs so I thought I better check the code to make sure it wasn’t already doing something like that. Sure enough, there’s a function called paredit-insert-html-examples that will format a nice HTML reference card for you. What I did was open an empty file called paredit.html and then call paredit-insert-html-examples. Next I saved the file and then opened it with my browser and set a bookmark to it in my Docs section. Now I have a nicely formatted reference card complete with examples and I know it’s correct because it’s generated from the actual code in the package.

You may have seen a version of this reference card on the Internet. It’s not this one, which is nicer looking but not complete. Here’s a older version of what gets generated. If you’re new to paredit or the type of person who doesn’t remember key sequences unless you use them all the time, this may be just what you need and it’s easy to generate when new versions of paredit come around.

Irreal readers who follow the comments will be familiar with Fuco, one of our best EmacsGolf/VimGolf in Emacs solvers. In addition to making me feel inadequate about my Emacs Fu, Fuco is also the author of smartparens. You can think of it as a configurable paredit for when you’re not programming in Lisp (or are, for that matter).

If you’ve been wondering about smartparens, Fuco has produced two videos that show off its capabilities. They’re only 24 minutes together so there’s no reason not to take a look to see if smartparens might be useful in your workflow. At the very least, you’ll probably do better in the EmacsGolf challenges.

Smartparens Video – Part 1
Smartparens Video – Part 2

Bozhidar Batsov is blogging up a storm on his new Emacs Redux blog. The other day, he mentioned a couple of useful modes that, since Emacs 24.1, are built in. The first is electric-pair-mode. It provides the automatic pairing of special delimiters such as “, (, [, and {. Much like paredit, when you type the left character of the pair, the right character is also inserted and the point is placed between them. Typing the right character merely skips over the already inserted right character rather than inserting a new one. You can insert just a single character by preceding it with the quote sequence 【Ctrl+q】.

I didn’t realize this was a built-in and have been meaning to install the package. It was a nice surprise to learn that all I needed to do was enable it.

The second electric mode is electric-indent-mode. It’s purpose is to automatically indent the next line after you type certain characters such as a newline. I already have 【Return】 mapped to newline-and-indnet so this is less useful to me and I haven’t enabled it. You may find it useful, though. Be aware that it reportedly causes problems with Python mode so be alert.

Xah Lee has a nice post that shows how to open files in an external app or on the desktop from Emacs. When opening files in an external application, the current visited file will be opened unless you’re in a dired buffer in which case all the marked files are opened.

There are two functions: one to open the file(s) in an external application and the other to open the current file in the OS’s file manager. In the first case, “open” means to do whatever clicking on the file would do.

What I like about this code is that it handles the three cases of Windows, OS X, and Linux. In each case you have to do something a little different. Even if you don’t have a need for these functions, the Elisp code is handy as a go by for writing functions to perform similar tasks.