Irreal

Jonas Bernoulli (Tarsius_) has just announced the release of Magit 4.0. The release, as he says, has been a long time coming: it’s been about 3 years since the last release. It’s great to hear about the new release and Bernoulli says that his goal is to make about 8 releases a year going forward. His announcement doesn’t list all the changes in the new release but you can take a look at the release notes if you’re interested.

Much of Bernoulli’s announcement discusses his plans for the future of Magit but he also mentions that he is a full time FOSS developer and community support is his only source of income. He says his income is about half of the median professional incomes in his area. That means two things for the rest of us:

• We owe Bernoulli a huge debt of gratitude.
• More importantly, we should try to support him as much as we can. For many of us, that probably means we are limited to occasional one time donations. Those all help, of course, but what he really needs is more significant, recurring corporate support. If you’re in a position to influence your company about this, please do.

Bernoulli has a list of several ways to support him at the end of his post. Take a look and please try to help him out if you can.

David Wilson over at System Crafters has an interesting video that explains his system for using tags on his Org tasks. The nice thing about his method is that it’s easy to implement. The hardest part is choosing a list of tags that makes sense for your workflow. Wilson has some suggestions that he used to pick his list.

Once you have the list of tags, everything else is mechanical. The best idea is to add the tags to the org-tag-alist variable so that you enter them easily—with a single key— when you’re adding a new task. Wilson’s example has 3 different files that contain his tasks according to what type they are. I use a template for entering my tasks but Wilson shows how to do it by simply adding a new line to the appropriate file.

When you want to work on tasks with a specific tag, you need only bring up the agenda and filter by the tag(s) you’re interested in. Take a look at the video for the details and to get a sense of how using tags can improve your workflow.

The video is 20 minutes, 36 seconds long so you’ll need to schedule some time but you’ll probably find it a worthwhile investment. As I said, the method is pretty simple and easy to implement. And using templates to enter your tasks will help even more.

Charles Choi has made another update to Casual Calc. This time it’s to provide a more contextual workflow. The idea is that that the Casual Calc menus should reflect the current context.

I haven’t yet had a chance to play with this latest update but I can say that Casual Calc has made it a lot easier to deal with calc. Instead of trying to remember a bunch of obscure calc commands, I can simply call up the Casual Calc menu.

If you aren’t familiar with calc, you really should be. I’ve described it as a sort of light weight Macsyma that is surprisingly powerful. The problem with it is that it’s virtually impossible to remember all the commands. Choi’s Casual Calc menu helps a lot with that.

I use Calc as my (only) calculator and have always been happy with it. The addition of Casual Calc makes it even better. You should really give it a try.

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.