Vi(m), on the other hand, is proudly simply an editor. They consciously eschew the Emacs “do any- and everything” philosophy. Their philosophy is do one thing and do it well. That one thing is, of course, editing.

Thus, when the two sides meet in battle they are really talking about different things: Emacs users about a customizable work environment and Vi(m) users about an editor. It’s no wonder they can never agree. Of course, a lot of it is probably just the geeks’ love of arguing about who’s tool is better but Harms’ take makes it sound so much more high minded.

Finally, I’ve found someone who agrees with me. Donald Curtis, also known as Milkypostman, the proprietor of the Melpa archive, has a post in which he advocates keeping your Emacs configuration in a single file. His configuration is well organized and easy to navigate. It shows, I think, how a single-file Emacs configuration can be easier to use and navigate than an equivalent multi-file version. You mileage may vary, of course, but at lease I don’t feel so lonely.

Whatever you predilections for Emacs configurations, you should take a look at Milkypostman’s post. He’s got some good ideas (such as his after macro) that are useful no matter how many files you have in your configuration.

If you find yourself needing to do this more than once a month, it may be worth your while to add Lee’s code to your .emacs or init.el file. I especially like the way it handles regular files and URLs. If you have special related needs, it would probably be easy to adapt Lee’s code to meet those needs as well.

I like this type of thing because it gives me a single place to go when I’m looking for subject matter about a topic. It means I need only remember—or bookmark—a single page rather than potentially hundreds of them. We have resources like EmacsWiki, of course, but that offers a more in depth look at certain areas of Emacs and is harder (although possible) to use to find, say, Emacs videos. The Emacs resource list on reddit is still rather short but as I mentioned they’re taking additions so it has the potential to grow into something more comprehensive.

I, however, have a different strategy. I have 4 or 5 files that I use all the time. I have them bookmarked so I can load them easily but I don’t need to do that very often because I just keep them loaded. I use desktop-save-mode so they stay loaded even across Emacs invocations. Then when I want to examine, say, init.el it’s just a matter of 【Ctrl+x b】 in or maybe just 【Ctrl+x b】 i depending on what ido has in its cache at the moment. That’s not as fast as Batsov’s 【Ctrl+c I】 but it’s fast enough¹.

One of the commenters to Batsov’s post suggests using the bookmark facility with a label of, say, i for init.el. Then you can open init.el with 【Ctrl+x r b i】. That gives us at least 3 ways of solving the problem, which is really the point. With Emacs you can solve problems in a way that’s comfortable for you. How do you solve the problem of opening frequently accessed files?

Really, it’s hard to see what they could have been thinking. I understand the need of some people to have a detailed plan before starting to cut code but jeez! It makes you wonder (in a staring at a train wreck sort of way) what the rest of the standard looked like. But, of course, it was the government.

Brent Jensen, over at Stormpath has an informative article on the 5 Myths of Password Security. It’s written with the password user—rather than the Website—in mind. It offers some reasonable suggestions for picking passwords and disabuses users of beliefs in some silly notions like big Websites can be trusted to store your password safely.

Most Irreal readers are probably familiar with this material but it’s worth taking a look just to see if there’s some little nugget you didn’t know. Be careful of the comments, though. There’s some misinformation there.

Ritz’s post is an exhortation for Emacs users to give key-chord-mode a try. He mentions how he uses it and suggests some strategies for picking chords. You may or may not find his use cases and suggested chords compelling but you’re almost sure to find the mode itself very useful. You can see my own use cases and chords in my previous post about it and, of course, you should watch the Emacs Rocks! video for some more.

Although some Emacs users apparently are put off by the idea of key chords, I find the idea a huge win. I originally mapped jump-char-forward to 【Hyper+f】 and still maintain that mapping but after Sveen’s video I also mapped it to 【f g】, the chord he suggested. I can’t remember the last time I used 【Hyper+f】 because the chord is so much easier, faster, and natural.

Now The New Yorker is setting up a similar facility under the name Strongbox. Unlike the Journal, they appear to have gotten things right¹. Whistle blowers connect to a private segregated server through the Tor network. The New Yorker does not log their IP addresses (which would be useless anyway with Tor) or set cookies on their machines. Each user is given a random ID to serve as a name so that no one at The New Yorker knows their actual identity. If the New Yorker needs to communicate with the user, they leave a message on the server under the user’s ID; the user is responsible for checking for responses. The New Yorker has no other way of communicating with the user. The actual protocol The New Yorker uses takes additional steps to insure the user’s anonymity.

The software that Strongbox uses is called DeadDrop and has an interesting backstory described by Kevin Poulsen. Its chief designer and coder was Aaron Swartz, long a champion of open government as well as open data. DeadDrop is open source software made available under the GPL. If Strongbox and other future DeadDrop sites prosper and help turn over the rocks hiding corruption, it will be another fitting legacy for a man who gave everything for his belief in our right to know.

Happily, Elisp is one of those languages. If you’re not already familiar with the Emacs implementation of hash tables, you can get the details in the manual (of course) but Xah Lee has an excellent overview that will get you up and running quickly. There’s not much to learn and hash tables are incredibly useful when you need a fast look up data structure so give Lee’s post a look and see if they can be useful to you.