Irreal

Marcin Borkowski (mbork) has a really great post about arranging for certain commands to prompt for verification before executing. Usually, those prompts are simply annoying but sometimes they’re actually useful. For example, you can arrange for Emacs to ask you for confirmation before exiting. Normally that would be really annoying but after I accidentally exited Emacs several times by fat fingering some shortcut, I began to appreciate its usefulness.

Some, dangerous, commands always prompt for approval. Others, like kill-emacs don’t ask for approval by default but can be configured to do so to help those like me who are prone to fat fingering. But, of course, most commands don’t ask for confirmation and don’t have a configuration option to enable it.

Mbork gives an example of a command where he wanted approval before it executed. I have another: Several times I fat fingered the command to print the current buffer—which always seemed to send my printer into a schizophrenic fit—and finally decided to do something about it. But what?

Mbork has two suggestions. He first thought about advising the function he wanted to protect—that’s what I did with print buffer—but then it occurred to him there was a builtin solution. He realized that he could simply mark the function in question as disabled and Emacs would automatically prompt before executing it. Even better, you can also specify what the prompt will be.

But wait! There’s more. While researching that solution he discovered the command command-query that does exactly what he wanted. You can check out his post for the details but the TL;DR is that if you want a prompt before executing a given command, command-query is the solution.

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.