Irreal

Here’s a tiny tip from Zachary Kanfer. Like me, he prefers to keep his Emacs windows the same size. That’s pretty easy to do: when you split or delete a window resulting in an unbalanced layout, you can merely call balance-windows with Ctrl+x +.

I tend to stay with two windows so this doesn’t come up often for me but Kanfer has a richer window environment and one day he realized that he was doing too much manual work keeping his windows balanced. He noticed that they became unbalanced when he deleted or split windows so he wrote 4 lines of Elisp that arranged for those functions to call balance-windows after they ran. Now he longer has to think about balancing his widows; it just happens.

Aditya Athalye had declared Emacs configuration bankruptcy and decided to start over emphasizing package management. He decided to build his own configuration as opposed to relying on a starter package: build vs. purchase as he put it. He started by using some of the ideas in Bozhidar Batsov’s prelude distribution but depends mostly on John Wiegley’s use-package package.

Athalye believes that one of the secrets to sustainable Emacs configuration is to let software write as much of the boilerplate as possible. That’s precisely what macros do, of course, so he relies heavily on the use-package macro to write most of his package installation code. Using use-package has several advantages.

Not only does it take care of that boilerplate saving time in writing it and time in debugging errors from getting it wrong, it also simplifies your init.el file. The nice thing about it is that can also handle installing a package if it’s not already present. Once the package is present, the use-package also provides the configuration, including any keybindings the user might desire.

Athalye includes a copy of his init.el so far. It’s a work in progress and he indicates some of the things still to be done but the package management facilities are all in place. He makes a good case for using use-package and you should check it out if you aren’t already using it yourself.

I long ago converted all my require commands, except that for use-package itself, to the macro and have never looked back. It makes my init.el file simpler and more coherent. Take a look at Athalye’s post for a bit more information.

Over at the Emacs reddit, Gink0 asks What dev feature is available in emacs but not in the current mainstream IDEs? It’s sort of like the usual question of “What makes Emacs so great?” or “Why do you recommend Emacs?” but with the added constraint that it has to be things that other editors don’t have.

For me, the salient feature is that Emacs provides the closest thing we have to a modern light-weight Lisp Machine. It’s not the “Lisp Machine” part that matters, of course, it’s what “Lisp Machine” is shorthand for: a complete, totally, configurable, and even reprogrammable operating environment. That means that can do just about anything you do on a computer in Emacs and do it with a unified interface.

Many of the responses to Gink0 hinted at this but emphasized the configurability that Emacs has far in excess of other editors. Other responses mentioned Org mode and its enabling of literate programming. Other editors may support literate programming to varying degrees but Org mode’s code blocks are special. Not only can you have traditional literate programming in the Knuth sense but you can also embed executable code in an Org file and have the results of running that code appear in the file. It’s tremendously powerful regardless of whether or not you like Knuth’s version of Literate Programming.

Those are the big things. Some of the commenters mentioned smaller things such as narrowing, rectangular editing (although lots of editors have that), the best Vim emulation, undo tree, Eshell, and the notion of modes.

What’s on your list?

Mike Zamansky has the third video in his Learning Elisp series up. As promised, this one is about writing functions. As Zamansky points out, Elisp functions are pretty much the same as function in other languages except for the lack of a return statement and, of course, the syntax.

There are a couple of interesting aspects to Elisp functions. The first is the Doc String. Lots of languages have something similar but in Emacs the Doc String is automatically imported into the Help system so a user’s own functions are documented just like the built-in functions.

The second aspect is the interactive declaration. Including it makes the function “interactive”, which means that you can call it from the keyboard with Meta+x or by assigning it a key binding. My goal for writing Elisp is to write an interactive function where I remember to add the interactive declaration before I try to run it from the command line.

The video covers just the very basics of writing functions. Zamansky is planning on getting into some of the deeper aspect in later videos. This video is 12 minutes, 36 seconds long so you’ll probably have to schedule some time.

Mike Zamansky has posted his second Learning Elisp video. In this episode, he briefy discusses defining variables, both global and local. The rules are a bit different from most other languages but still simple enough to understand easily.

In keeping with his taking things slowly, he doesn’t mention the closely related concept of closure but presumably that will come after he’s laid a bit more groundwork. If you have any experience at all with Elisp, nothing in this video will be new but it’s just what a n00b needs to get started.

He was originally going to include functions in this video but decided it would be too long so he decided to defer functions to the next video. Once that’s done, his plan is to move into the “interesting stuff” and show how to use Elisp to write interesting and useful functions.

The video is 11 minutes, 58 seconds long so plan accordingly.

As most of you know, I’m a Mu/Mu4e user and have been very happy with it. It has, I think, the correct paradigm for handling stored email: everything goes into a single repository and emails are retrieved with its outstanding search capability. Stored messages are indexed so these searches are very fast. You can, of course, use the normal method of multiple mailboxes but why would you?

Another of Mu’s benefits is that it runs in Emacs. That’s a benefit that it shares with Notmuch a similar package that has excellent search and indexing too but also implements a tagging workflow.

Michał Sapka was tired of using Webmail because of its inflexability. He used Neomutt for a while but decided he’d like to fold his email into Emacs. He quickly settled on either Mu/Mu4e or Notmuch and—apparently randomly—chose Notmuch. That was a good choice for him because his workflow includes working with GitHub Pull Requests and he brilliantly leverages Notmuch’s tag system to automate it as much as possible. He goes into detail on how his workflow functions so be sure to take a look at his post.

Another nice thing about his post is that gives an excellent explanation on how to configure Mbsync. If you’ve been around Irreal for a while, you may remember that that was the thing I had the hardest time with when I moved to Mu4e. It’s definitely a worthwhile post if you want to move your email to Emacs.

Dmitriy Pshonko has an interesting project for those of us who like to (a) stay in Emacs and (b) use the mpv media player. The idea is that you can list your media files with dired and it will tell you where you left off in the file if you started but did not complete it. Files that you’ve completed are marked done and the rest are simply listed.

I almost always consume these files in one sitting but sometimes I get interrupted and it would be nice to have a way of picking up where I left off. I don’t use mpv so I haven’t installed this package but if I did use mpv, I certainly would. It’s in MELPA so installation is simple and configuration consisted of setting a hook. The README explains how to do this directly or with use-package and is in any event a one liner.

If you’re an Emacs and mpv user, this package seems like a very nice addition.