Irreal

Sacha Chua has chatted with John Wiegley several times (see here, here, and here). Wiegley’s an interesting guy and all those chats are well worth watching. Recently, as Irreal readers surely know, Wiegley was named the new Emacs maintainer so Chua recorded another session with him.

This is a really interesting chat. They cover two main subjects:

• Wiegley’s workflow as Emacs maintainer
• How Weigley is trying to improve the Emacs community and make it easier for people to contribute

The chat starts with some of the technical means that Wiegley uses to stay on top of Emacs development. A large part of that is his use of Gnus to manage the emacs-devel mailing list. As it is, he spends about 2 hours a day reading the list and it would doubtlessly be much more without his leveraging of Gnus to keep the process under control.

In the video, Wiegley shares his screen and shows how he uses Gnus to manage the list. It’s very impressive and a real incentive to suffer through the steep Gnus learning curve if you have similar needs. He also shows how he integrates Org mode into the process. Wiegley says that Gnus and Org are his two main Emacs tools.

On the non-technical side, Wiegley discusses some of his plans for Emacs and how we can all help. He’s changing some of the processes to make contributing easier and allow even those without advanced technical skills to help out. I was struck with how earnest he is in his desire to improve the community. He says that he is currently spending most of his time on these softer issues rather than generating code.

If you’re an Emacser, you really should watch this chat. It will give you a good idea of where Emacs is going and Wiegley’s vision for how we’re going to get there. As I wrote at the time, I was very happy when Wiegley was chosen as the new maintainer. After watching this video, I’m even happier and more confident than ever that he’s going to do a great job.

Over at Coding Quark, Dhavan Vaidya has a nice post on getting started with Emacs. Rather than talk about keybindings and navigation, he concentrates on the things you should do and the resources you should read to get going with Emacs.

My favorite part is the section on why you should use Emacs. Here he lists what experts such as ESR and Batsov have to say on the matter. This part makes much of the killer feature of Emacs: its extensibility and openness. Although he doesn’t use the term “Lisp Machine,” he essentially describes one and the advantages that it brings.

If you’ve been thinking about trying Emacs, you might enjoy this post. Even if you’re already a user, you may find it useful as a sort of bias confirmation.

Eric Cole has an interesting post on decreasing the Emacs load time. This is not something I’ve ever worried about because I tend to load it once when the machine boots and just keep it running. It makes no difference to me if it loads in 1 second or 10.

Cole looks at two strategies. The first is essentially what I do except he runs Emacs as a demon that gets started at boot time by systemd. I could do that too but I don’t bother. I just start it when my OS X desktop comes up.

The second approach is to profile Emacs’ startup, identify the hot spots, and do something to eliminate those hot spots. He does his profiling with profile-dotemacs. You can check his post for how he dealt with some of the startup time eaters.

As Cole says, lots of people enjoy spending hours to shave half a second off their load time. He even remarks that it helped him learn Emacs and become more efficient with it but worrying about load time always strikes me as fundamentally wrong-headed. If you’re worried about how long Emacs takes to load—assuming here that you don’t have some misconfiguration that makes it take a minute or more—then you’re probably importing habits you learned from another editor.

When I used Vim, I just started it every time I needed to edit something. It loaded almost instantaneously so there was no downside to that strategy. Experienced Emacsers tend to leave Emacs running and just pop open another buffer when they have something new to edit. As I say, who cares if it takes 10 seconds instead of 1 second to start? You hardly ever start it.

Still, if you enjoy fiddling with your init.el trying to wring out every unnecessary cycle, Cole’s post may give you some ideas.

Fuco, the author of the excellent smartparens package, has a collection of useful additions to dired. Rather than define a comprehensive package, he broken the functionality out into separate packages so that you can install just what you need.

He has a detailed README that describes the functionality of each package so you should take a look at that if you want details. Here’s a quick summary of the packages

• dired-filter
  Filter the dired listing by one or more criteria. These are ANDed together by default but can also be ORed or NEGATED.
• dired-avfs
  Seamless archive browsing. Requires avfsd.
• dired-open
  Improves upon the functionality that opens files with external programs
• dired-rainbow
  Extends the highlighting functionality
• dired-subtree
  Improves the formatting of dired subdirectory listings
• dired-ranger
  Adds some functionality from the ranger file manager that is missing in dired.
• dired-narrow
  Provides a sort of live filtering in dired buffers.
• dired-list
  Make a dired buffer from the output of a shell script.

If you like to anchor your workflow in a dired buffer, you may find some or all of these packages helpful.

A year ago I wrote about Artur Malabarba’s excellent narrow-or-widen-dwim function. Ever since I installed it, I don’t think I’ve once called one of the narrowing functions directly. Since then, Malabarba has posted some updates to his original post making the code better.

His latest update makes it work with any type of block supported by org-narrow-to-block. If you use narrowing at all, you should definitely install his narrow-or-widen-dwim function. It will do everything you need without having to remember all those other keystrokes. Malabarba has even replaced the normal narrowing keymap with a direct call to his function. If you are already using his function, take a look at his latest update.