It’s been a while since Irreal has had an EmacsGolf challenge but yesterday’s post on Programming Silliness suggested a nice one. When I ran the grep, I got
| A |
| a |
| aa |
| Ab |
| aba |
| … |
| faff |
| fe |
| fed |
| fee |
| feed |
The challenge is in two parts:
The other day I saw this post. Although I’m not interested in Java, I was struck by the magic number CAFEBABE that marked the beginning of the structure. That got me wondering how many words can be made with the hexadecimal digits A-F. Before you read further, ask yourself how you’d go about solving this problem.
Being a developer, my first thought was, “Well I’ll just write a quick Lisp program.” The only aspect I wasn’t sure of was whether I should use Common Lisp or Emacs Lisp. It was pretty easy to layout the general structure in either language.
Then I had that “DUH” moment when I realized I was working way too hard. The easy way to solve this problem is
grep -v [^a-fA-F] /usr/share/dict/words
which gave me the results
| A | a | aa | Ab |
| aba | abac | abaca | abaff |
| abb | Abba | Abe | abed |
| acca | accede | ace | ad |
| Ada | Adad | adad | add |
| Adda | adda | added | Ade |
| ade | adead | ae | aface |
| affa | B | b | ba |
| baa | Bab | baba | babe |
| bac | bacaba | bacca | baccae |
| bad | bade | bae | baff |
| be | Bea | bead | beaded |
| bebed | bed | bedad | bedded |
| bedead | bedeaf | Bee | bee |
| beef | C | c | ca |
| cab | caba | cabda | Caca |
| cad | cade | caeca | caffa |
| ce | cede | cee | D |
| d | da | dab | dabb |
| dabba | dace | dad | Dada |
| dada | dade | dae | daff |
| de | dead | deaf | Deb |
| deb | decad | decade | dee |
| deed | deedeed | deface | E |
| e | ea | ebb | ecad |
| Ecca | Ed | Edda | edea |
| efface | F | f | fa |
| Faba | Fabaceae | facade | face |
| faced | fad | fade | faded |
| fae | faff | fe | fed |
| fee | feed |
Sadly, cafe isn’t in the system dictionary on my MacBook but the method stands.
The moral here is that we developers should remember that not every problem is a nail. Now that I think about it, this is the exact same point that I made two years ago.
A couple of weeks ago, SBCL 1.2.1 came out and as I reported at the time, although it compiled and installed correctly, there was a problem with Slime. The 1.2.1 SBCL release changed some internals that Slime relied on and as a consequence Slime wouldn’t compile.
Now Xach has released this month’s Quicklisp distribution with a new version of Slime that fixes the problem. I reinstalled SBCL 1.2.1, fired it up, and everything was fine. If you had the same problem, it’s now safe to install the latest SBCL. If for some inexplicable reason you’re not using Quicklisp, just grab the new slime from GitHub.
Even if you didn’t have the problem, it’s worth noting that the new Quicklisp distribution is available. As usual, there is lots of goodness in it.
Continuing with our theme of using Emacs for writing rather than coding, Mark Szepieniec and Christophe-Marie Duquesne have a couple of nice posts about writing your résumé in Markdown and then exporting it to the desired format with Pandoc.
There’s a lot to be said for this strategy. You can have a single master copy for your résumé and use it to generate whatever format is needed. The same master copy can generate a nice HTML for your Web site, a PDF for an employer that prefers a traditional format, or a Word document for employment agencies, which generally prefer that format. If you try to keep separate copies for each of these different formats, errors are sure to creep in and some formats will have the latest updates missing.
Both these posts discuss using Markdown for your master copy but exactly the same strategy works for Org-mode. You might not even need Pandoc with Org-mode because of Org’s powerful export engine. Either way, I think the Markdown/Org-mode method is the winning strategy. You have a single, portable source for your resume that can be exported to just about any desired format. One thing for sure, it’s a lot better than using Word or one of its demonic spawn. It’s also better, I submit, than writing it in TeX or LaTeX for many of the same reasons.
Like many (most?) Emacs users, I do all my writing with Emacs. This mostly involves Org-mode but even when it doesn’t I’m still in some sort of Emacs buffer. I just came across this old Stack Exchange post asking about Emacs configurations for creative writing.
If you’re looking for an excellent writing tool, you should check out this thread. Also be sure to follow the link to Randall Wood’s Woodnotes Guide to Emacs for Writers. It covers those aspects of Emacs most likely to be useful to writers. Wood doesn’t consider coding at all, only creative writing.
I know many writers like tools such as Scrivener for organizing their writing. While I’ve never used any of those special tools—let alone the horror that is Word—I find it hard to believe that an appropriately configured Emacs is not equally good or better. One of the nice things about writing with Emacs and Org-mode or Markdown is that you can export to Word format with Pandoc or Org’s export engine. That’s really handy because you can write with a decent editor and still provide your publisher with the Word document that most publishers insist upon.
It’s an interesting thread. If you do any writing, especially creative writing, you should check it out.
Update: Randal → Randall
Many of us have benefited from Xah Lee’s Emacs Lisp tutorial. I found it very useful for learning the Elisp library and idioms. Now Lee has put together a JavaScript tutorial.
When I was learning Elisp, I had the advantage of already being familiar with Common Lisp and Scheme so I understood the Lisp parts. It was just the Elisp specific bits that I needed help with. In the case of JavaScript, I’m a complete novice as I don’t know the language at all. It’s enough like C that I can get a general idea what a simple program is doing but I certainly couldn’t write in JavaScript or even understand anything harder than a toy program.
That makes me a perfect test case for Lee’s tutorial. I’ve gone through the first section (8 lessons) and learned a lot. I don’t have much interest in writing large JavaScript programs but I would like to have enough facility that I can read and understand others’ work and write my own (possibly simple) programs when necessary.
It’s still too early for me to say I’ve reached that goal but I do understand some of the things that confused when I looked at JavaScript scripts before. If you’ve been wanting to learn JavaScript, Lee’s tutorial is an easy way. You can go through a lesson or two a day in just a few minutes so it doesn’t require a large time commitment. Perhaps I’ll write a followup post after I finish the tutorial. In the meantime, I’m enjoying it and learning a bit of JavaScript.
Over at NetworkWorld they have an interesting article featuring the 14 greatest living programmers. I was a bit surprised that DMR wasn’t on the list but then I remembered the part about living. Also, oddly, you and I aren’t on it either.
The latter shocking omissions aside, I think you’ll agree that the 14 are world class engineers. Perhaps your favorite isn’t there but by and large it’s a good list. My only complaint is that the article is in the form of one of those obnoxious slide shows designed to maximize ad impressions.
Definitely worth a glimpse.
Some people are bad spellers or at least consistently have trouble with certain words. Others can spell but are poor typists and constantly mistype words. Some, I suppose, fall into both categories. If any of this describes you, don’t despair: Bruce Connor has a solution for you.
Over at Endless Parentheses he presents a bit of Elisp that will look up the correct spelling with ispell (or aspell or whatever you’re using) and make an abbreviation for your incorrect spelling so that it will be automatically corrected in the future. It’s probably not for everyone but if you consistently make spelling errors—for whatever reason—it may be helpful.
Endless Parentheses is a fairly new blog that concentrates on short, mostly weekly, Emacs-oriented posts. As of this writing there are only eight short posts so you might want to read them all. It won’t take much time and you’ll probably learn something.
My init.el isn’t very organized. Partly, that’s because I like having a single file rather than the multitude of special configuration files that many of my Emacs heroes prefer. But even given that it’s a single file, it’s not really organized. I have sections that more or less group functionality but like many Emacs configurations it has grown (some would say metastasized) over the years and accumulated a thick layer of barnacles.
Now Grant Rettke has shamed me even more by publishing his configuration. It’s a wonderful example of literate programming. Others have used Org-mode and Babel for their Emacs configurations but Rettke’s is a marvel. It’s really more of an essay that explains what he’s trying to do, why he chose each configuration item, and even why he didn’t choose others. He has a long section on key bindings, what he was trying to accomplish, and what he finally chose.
It’s worth reading through his configuration just for some of the ideas. I learned about packages and settings that I wasn’t familiar with. The easiest way to do that is to read the TC3F.txt file because it’s nicely formatted. Ideally, you’d want to read TC3F.org but for some reason GitHub displays it in raw mode rather than the nicely formatted mode that GitHub usually uses for Org files. It’s also worth taking a look at the makefile to see how he builds init.el from his TC3F.org file.
Most readers will probably find Rettke’s Org file overkill—it’s 4,460 lines long—but I like the idea of documenting why you made the choices you did and what a particular piece of code is doing. The table of contents at the beginning makes it easy to locate a particular part of the configuration. In Rettke’s case there’s the extra step of building the configuration file by running the makefile but these days I usually only make a couple of changes a month so it’s not much of a burden, at least for me. If that bothers you, you can have it loaded automatically by bootstrapping it from a minimal init.el as Sacha demonstrates with her configuration.
My point in writing about Rettke’s configuration is not that I think everyone will want to have the same kind of comprehensive document but that it serves as an excellent example of how you can use literate programming for your Emacs configuration. As I said above, it’s worth reading through the TC3F.txt file to find packages and features that you didn’t know about and the TC3F.org file to see how you can put together an Emacs configuration using literate programming methods.
The invaluable Mickey has an excellent post up on proced, a ps/top-like utility built into Emacs. If you find yourself using top and ps—and what serious developer doesn’t?—you’ll love having the functionality built right into Emacs. One more reason not to leave the comfort of your editor.
As usual, Mickey explains the functionality in detail so I’ll just send you to him for the full picture. Sadly, if you’re an OS X user, like me, proced won’t work because OS X lacks /proc. It’s doubly insulting that it does work under Windows. If you’re a Linux or Windows user, check out Mickey’s post and enjoy and power. If you’re an OS X user, have a beer and weep into it. I feel your pain.