Irreal

My last Red Meat Friday rant was about the desire for minimal Emacs configurations on the part of some people and how I didn’t understand what they were perusing. Sebastián Monía, a frequent Irreal commenter, has his own take on the matter that he wrote about on his blog. He makes the case for a minimal configuration but at the end of the day, I don’t think we disagree.

He lays out why he prefers to use builtin functionality when he can. But the thing is, no one is arguing against that. I, too, prefer to stay in vanilla Emacs and add third party packages only when they provide something missing from the default install. That’s why several of the third party packages I’ve installed have since been moved to core: they fulfill a real need. Monía says that his configuration is about 1,700 lines. After more than 17 years with essentially no culling, mine is less than 2,500 lines including comments and code that I’ve commented out “just in case” I might need it later.

Both of us, I think, add packages only when they provide something new that can help with our workflow. As I said in my original post, I spent many years with just vanilla Emacs before I started adding any packages.

The desire to keep our configurations as simple as possible is different from seeking a minimal configuration for its own sake. You can tell the difference by the way people talk about it. If they say, “My configuration is less than X lines” or “My configuration is too long at Y lines” that’s probably a sign that they think a small configuration is a good thing per se.

Of course, it’s not a mortal sin to want a minimal configuration. It’s just, as I said before, that I don’t understand what the people pursuing it are after.

There’s a long simmering debate among hardcore Emacsistas about who what did what in the initial development of Emacs. Most of us know that Emacs began as a curated set of editing macros for the TECO editor. At the MIT AI Lab where all this happened back in 1976, virtually everybody used TECO but they all had their own set of macros.

In order to bring a little rationality to chaos, RMS and Guy Steele decided to select the best macros and offer them as a standard macro set. When you put it that way it doesn’t seem like much of an effort but there as a lot of work by a lot of people just to get things running the way they wanted them to.

All this was almost 50 years ago so of course memories are dim and there are disputes as to who was involved and how much they did. Jeremy Bryant has an interesting blog that considers Emacs, Lisp, and related matters. One of his entries considers the origin of Emacs. To some extent it depends on the recollections of those involved but Steele had a bunch of emails that he contributed to a long thread on Dan Weinreb’s blog.

The TL;DR is that RMS did most of the heavy lifting almost from the beginning. For the first few weeks Steele was heavily involved as were others. Take a look at the blog for the details. A lot of the discussion presumes a knowledge of TECO and its macro system but it’s possible to figure what was going on and who the major players were.

Emacs evolved significantly from those seeds and again RMS put in a huge amount of work. No Emacs user needs to know any of this, of course, but hard core Emacsers will probably find it interesting.

It’s getting harder and harder to keep up with Charles Choi and his casual-suite. He’s announced yet another app in the suite. This time it’s for bookmarks. Like the other apps in the collection, casual-bookmarks captures all the hard to remember commands in a transient menu so you don’t have to remember them. If, like me, you use several of the Casual apps, you can bind them all to the same shortcut so that there’s hardly anything to remember.

I use Bookmarks+ and have ibookmark-jump jump bound to a hydra that collects other window commands that I use frequently. Using a hydra is basically the same as using transient except that transient is builtin. Some folks prefer transient to hydra but they seem the same to me.

That said, my hydra has no bookmark commands other than bookmark-jump. I virtually never use those other commands except when it comes time to change my current tax file from one year to the next and then I just stumble about with which-key until I find what I need.

But that’s me. If you have the need to interact with the deeper layers of the bookmark system more often than I do, Choi’s app is probably just what you need. As with the other Casual apps, the menu stays out of sight until you explicitly call it and disappears as soon as it does what you
asked it for.

Take a look at Choi’s announcement for the details and to see what the menu looks like. If you’re a dropdown menu user, Choi has a link to a previous post that shows how to implement a menu for the bookmark system.

Protesilaos Stavrou (Prot) has an excellent video on the fundamentals of the use-package macro. If you’re new to Emacs or are one of the few Emacs users who isn’t constantly tweaking your init.el, use-package is a macro you use in your configuration files that makes it easier to configure packages. One of it’s major features is that it automatically defers loading packages under several circumstances resulting in a decreased load time. That feature is especially useful for packages that you seldom use: they won’t be loaded until you actually need them.

The rules are a bit more complicated than you might think. Prot goes through several examples that illustrate how use-package decides what to load, when to load it, and how and when to configure it.

As of Emacs 29, use-package is builtin. Before that, it was a package from John Wiegley that lived on ELPA. Now that it’s builtin there’s no longer a need for special hacks to get it loaded before the rest of your configuration is processed.

When I converted my configuration to use-package, I simply searched for every instance of the require command and replaced it and the subsequent package configuration with a use-package call. There are doubtless exceptions but a good first approximation is that any require for a package should be replaced with use-package. It simplifies your init.el and, as I said before, can reduce your startup time with no effort on your part. Take a look at Prot’s video for the details.

The video is 35 minutes, 44 seconds long so you’ll have to schedule some time but it’s definitely worth your while. Now that it’s builtin, there’s no reason for not using it.

Nathan Dawit Chane has an interesting post on his journey from Vim to Emacs. I can relate to it because his journey is eerily similar to mine. Like him, I spent many years as a Vim user and could be legitimately said to be an expert user.

Like him, I tried Emacs several times but it never stuck. Unlike Chane, I gave up for trivial reasons. I didn’t like the default scrolling and “yank” meant precisely the opposite of what I was used to. Like Chane, I finally moved to Emacs because I started doing all—or at least most—of my programming in Lisp. Emacs—Paul Graham notwithstanding—is simply a better fit for that type of programming. I’ve sacrificed billions of pixels explaining that concept so I won’t relitigate it here.

What finally worked for Chane was to start with a simple Emacs install—complete with the standard Emacs bindings—and become comfortable with that before adding packages. When I started, before ELPA, adding packages was a lot harder so I spent a lot of time just getting used to vanilla Emacs.

Like most of us, Chane came to realize that Emacs was not just another editor but another way of working. It is, as I often say, a light weight Lisp machine that provides an operating environment complete with its own Lisp based programming language. It also happens to have a pretty good editor built in. The thing about that “pretty good” editor is that like everything in Emacs it can be tweaked to make it perfect for you and your workflow.

My sense is that Chane has not yet completely embraced the Emacs way but that he is well on his way. As I often say, Vim is a great editor but it exemplifies another way of working. You may like the Vim way better, which is fine, but if you’re looking for something that recapitulates the Lisp Machine way of working, Emacs is worth learning.

UPDATE [2024-07-27 Sat 17:07]: Added link.

Marcin Borkowski (mbork) has a very interesting post on something I didn’t know about: dedicated windows. The TL;DR is that dedicated windows are restricted—more or less—to the single buffer that they were displaying when they were set to dedicated.

Mbork’s use case is reading a technical book in one window while taking notes and trying code snippets from the book in another. He notes that if there’s an error when executing those code snippets Emacs will open an error window over your book. By marking the window as dedicated, you can avoid that and force Emacs to open a third window so you can see all the pertinent information.

Although dedicated windows have been in Emacs for some time, there’s never been an easy way of invoking them. That changed in Emacs 30. Now’s there a convenient key sequence to mark a window as dedicated (Ctrl+x w d).

To be honest, my workflow doesn’t have much use for this feature but, of course, that can change without warning so it’s nice to know that there’s a way of pinning a window to a particular buffer. If you think that you have a use for such a feature, be sure to take a look at Mbork’s post for the details. The easy UI won’t be available until Emacs 30.1 but you still set a window dedicated by calling the appropriate function. See the documentation for the details.