Irreal

Many people consider the Emacs *‍scratch*‍ buffer mysterious. This is true even though, by default, it includes a message telling you what to use it for. I like it and use it often. Others, not so much.

Despite that default message, I never use the *‍scratch*‍ buffer for notes (I use Org capture for that sort of thing) but I use it all the time for trying out a bit of Elisp or writing a function for my init.el file. It is true, though, that the majority of Emacs users don’t write in Emacs Lisp and really have no use for the *‍scratch*‍ buffer.

Most of us know that you can eliminate or change the message in the *‍scratch*‍ buffer but that doesn’t address any real problems. It is Emacs, though, so of course you can configure more than just the message. Bozhidar Batsov over at Emacs Redux has a nice post that shows you how to configure the default mode of the *‍scratch*‍ buffer. Thus, to use Batsov’s example, if you’re a Ruby programmer you can configure the *‍scratch*‍ buffer to use ruby-mode as it’s default mode.

I’m happy with having the *‍scratch*‍ buffer come up in Emacs Lisp mode but Batsov’s post may help make it more useful to others who aren’t Elisp programmers.

Chen Bin, who you may recognize from the Emacs and ErgoEmacs Google+ communities or from his blog, has an interesting essay on GitHub about how to master Emacs in a year. The essay is really the steps that Bin followed when he was learning Emacs. He has a lot of good advice and it’s well worth giving it a read, especially if you’re an Emacs n00b.

Old hands may or may not agree with everything he says but it’s all reasonable advice. He lists some good resources to help the beginner get up to speed. I’m always happy to see articles like this. They spread the word and help beginners learn about the glories of Emacs.

The other day I wrote about Emacs themes. It’s amazing how much difference a well chosen theme can make to your peace of mind and productivity. Just as important is the choice of a programming font. Fortunately, Emacs can support just about any font and can even look elsewhere for missing glyphs. It’s really just a matter of deciding on a font, installing it, and telling Emacs to use it.

Not all that long ago, monospaced fonts weren’t antialiased and were really ugly. Now there are several good, free fonts to choose from. Jacob Gube over at Six Revisions has a great article on 10 excellent free programmers’ fonts. Each font has a screen shot and additional information, including where to get it.

I’m a long-time user of Inconsolata, which is one of the fonts he lists, and am very happy with it. My only complaint with it is that the l (ell) and 1 (one) are a bit hard to tell apart. Some of the other fonts do better. Source Code Pro, for example has a very distinctive ell that can’t be mistaken for a one. Others have a distinctive one with an exaggerated serif at the top. Oddly, the otherwise excellent Droid Sans Mono has a zero and oh that are very difficult to tell apart unless you see them together.

If you’re looking for a new font or you just want to see some of the other choices, take a look at Gube’s article. It’s a nice set of choices and is sure to have something for just about everyone.

The other day I saw a nice bit of code from Michael Fogelman that implemented a “do what I mean narrowing” function. That seemed pretty neat and I made a mental note to add it to my init.el. Then Artur Malabarba over at Endless Parentheses, a site you should definitely add to your feed, took that code and improved it a bit.

His best idea, though, was to add it to his toggle map. Now, for almost all uses of narrowing, a single, easy-to-remember key sequence will do what he wants. That means he no longer has to remember all the different narrowing calls and their key sequences; he just has to type 【Ctrl+x t n】 and the desired narrowing takes place. I’ll definitely be adding his implementation to my version of the toggle map.

Over at lunarsite, Sebastian Wiesner has a very nice post that explains the ins and outs of autoloads in Emacs lisp. Mostly, autoloads take care of themselves but sometimes users do need to interact with them. Here’s an example that I learned from Steve Purcell.

Of course, if you’re writing packages you will need to understand how autoloads work and when to use them. Wiesner’s post gives you all the information you need. Definitely worth a read even if you’re not writing your own packages.