Irreal

All of us long term Emacs users have our favorite Emacs features. Sometimes it’s something big. For me that would be Org or Ivy/Counsel/Swiper. Other’s would choose Magit, Dired, Elfeed, or Mu4e. In a sense, those are the easy choices. But what about your favorite small feature?

There’s tons of little Emacs features that make our editing life easier. There are, for example, backward-kill-word and transpose-chars both of which I use all the time. Some of you will say, “Wha?! Who cares about that stuff.” Others will say, “Yeah me too.” We all have our favorites.

Fernando Borretti has his own favorite. In his case, it’s fill-paragraph. That’s a command that wraps the lines in your buffer to fit into whatever line length you’ve specified. I used to use it all the time too but have since moved to visual-line-mode that pretty much takes care of all that for me.

Borretti is especially concerned about maintaining indentation in his prose. I write all my prose with Org mode, which has markup to handle indentation so I’ve never had to worry about that. My main reason for moving to visual-line-mode was that fill-paragraph added hard newlines, which messed up the display on smaller devices like smartphones, while visual-line-mode deals with virtual lines that are reformatted by the target device.

Borretti says that fill-paragraph is what keeps him from moving to the Zed editor—it’s the little things that keeps us coming back. As for me, Emacs offers so many features and eases my workflow so much that I can’t imagine switching to anything else.

Here on Irreal, I often claim that Emacs is best thought of as a light weight Lisp Machine. One of the problems of being a gray beard is that it’s easy to forget that not everyone has your frame of reference. Things that seem quotidian to me are new concepts to younger members of our community.

One such concept, it seems, is the notion of a Lisp Machine. If you’ve been around a while, that term refers to a specific tangible thing that actually existed. Some younger engineers lack that frame of reference and don’t understand what the term refers to.

Lisp Machines were, of course, actual computers that ran Lisp natively in vaguely the same way that current machines run C natively. The OS and probably all the applications were written in Lisp on hardware that had explicit support for the Lisp language. They were meant to support research in artificial intelligence and other hard problems of the day.

At the link, Fit-Page-6206FUMA takes the term to mean a program that has a Lisp interpreter and wonders if we couldn’t have a, say, Lua or Java, machine. An actual Java machine would need hardware support for the Java language. That’s why I also say Emacs is a light weight Lisp machine. There’s no hardware support for Elisp; everything is done in software. Still, if you squint a bit you can almost believe you’re on a Lisp machine when you’re running Emacs.

One could claim that Emacs is a pale imitation of a real Lisp Machine and that’s probably true but it’s still so much better than everything else out there.

It seems de rigueur to complain about Emacs being slow on Windows or even, according to some, on every OS. It’s easy to throw out such aspersions but a lot harder to offer solutions.

RobThorpe over at the Emacs subreddit does have some suggestions. His first observation is that often the problems aren’t Emacs’ fault. His example is Git. It turns out that Git itself is slow on Windows and it doesn’t matter if it’s being invoked by Emacs, some other editor, or the command line; it’s always slow on Windows. There are other applications like that on Windows and elsewhere.

RobThorpe’s recommendations aren’t limited to, “suck it up, it’s your OS’s fault”, however. He offers several actionable recommendations that will help regardless on what OS you are running Emacs under.

One such piece of advice is to not turn on what you don’t need. That seems obvious but it’s easy to end up with functionality you don’t—or no longer—need enabled. That may be because you used to need it but no longer do or because a framework such as Doom loads it even though you’ve never used it.

Another point he makes is that most users don’t really need to reload Emacs all the time. I’ve said this over and over and it’s the reason that I don’t care at all about my Emacs load time (even though it’s relatively small). Most experienced Emacs users keep it running all the time even if it’s in demon mode. I don’t even bother with that. I just have an Emacs instance running all the time in a separate (OS) window.

The post has a few other suggestions and the comments also offer some good advice. Mostly, the differences in speed are undetectable to a human user so I’ve found it best not to obsess about them but if you’re seeing a lot of latency, take a look at RobThorpe’s post for some suggestions for improving matters.

This is a sort of public service announcement. As many of you know, I consider Ivy/Counsel/Swiper to be one of my most valuable packages. It’s a behind the scenes force in almost everything I do in Emacs. If it disappeared, my workflow would be seriously impacted for the worse.

Not everyone agrees. Alex Popescu recently disabled it on his system for reasons he says are too boring to go into. One of the problems that appeared immediately concerned completions. While Ivy handles this transparently, the default behavior is to pop up a temporary buffer with the completions. The problem was that the only obvious way Popescu could find to get to that buffer was to use the mouse. Like most Emacs users, he considered that an anathema.

He tried pop-to-buffer, which worked, but then he realized, that being Emacs, there was almost certainly a builtin command for such a fundamental action. There is, of course. The proper command is switch-to-completions. Popescu says that it is already bound to Meta+v but that’s not the case on my system. Perhaps Ivy modified it. In any event, be aware that you may have to bind it yourself.

If for one reason or another you’re not using Ivy or one of the similar packages this is a useful thing to know.

Update [2024-08-05 Mon 12:51]: Added link to Popescu’s post.

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.