Irreal

Charles Choi is on a roll. He discovered the trick of improving the interfaces to various Emacs functionalities by capturing them in a transient menu. I’ve already written about his considerable contributions to the usability of Calc: my last post is here.

Now he’s back with a nice interface to Dired. I do virtually ail my file operations with Dired but for whatever reason I don’t do a lot of them so whenever I want to do anything even slightly non-routine, I have to bring up the Dired cheat sheet, which I have bookmarked for easy reference.

Choi has solved that problem. Now a simple keystroke brings up the menu shown on his post and you can invoke any of the Dired functions right from the menu. Notice how it doesn’t get in your way. If you already know how to do something, you can just do it. If you can’t remember some command you can bring up the menu to invoke it and immediately return to your normal workflow.

I really like this package. It mostly stays out of your way but when you need it, it’s just a keystroke away. Doubtless Choi will make adjustments as he gains experience with the package but even now it seems like a win.

One of my everyday chores is to read through the Emacs and Org-mode mailing lists. I don’t read most of the posts unless they catch my interest but just checking the headlines gives me an idea of what’s going on. The other day, I saw this post asking why such and such a function was written in C rather than Elisp.

It’s a common question. Someone is reading through the source code, finds a function written in C, and thinks, “this code could/should be written in Elisp.” Everyone’s always complaining about the C core so why not reduce that C core as much as we can?

It turns out that it’s not just inertia as Eli Zaretskii tells us in his answering post. He explains in detail the problems that arise from making an apparently simple change like rewriting a function in Elisp. It’s not, as you might think, a worry about introducing a surface error due to the rewrite. It’s that the C core is available during the whole boot process but an Elisp function may not be so before rewriting a function in Elisp you have to make sure it gets loaded before any other function calls it. Sometimes that function, as the one under discussion, may be called from C, making it even harder to make sure it gets loaded before being called. See Eli’s post for a complete explanation.

Most of us, of course, wouldn’t think of all that. We’d merely say, “Yeah, of course, rewrite that sucka.” Those two messages gave me a renewed appreciation for Eli and the other devs who have to deal with keeping Emacs the world class editor that it is. It’s easy to think they’re just being overly conservative but it turns out they have good reason for their caution.

So I’d like to take a moment to thank all the devs for bringing their deep knowledge and caution to the task of keeping Emacs running. It’s harder than it seems.

Over at the Emacs subreddit, TheTwelveYearOld asks an interesting question: Would Emacs be more popular than Vim if it used modal editing by default? Experienced users will recognize that there’s an unstated premise buried in the question. The premise is that modality is what separates Emacs from Vim and that that modality is responsible for Vim’s greater popularity. That is, I think, a flawed premise. Vim’s real strength, in my opinion, is not modality but the regularity of its command set.

TheTwelveYearOld’s post has some other misunderstandings but the interesting thing about it is the comments. Most of those comments take issue with the notion that Vim’s popularity is due to its modality. Almost all of them ascribed Vim’s popularity to its ubiquitousness. If you log on to almost any Unix system, Vi(m) will be there so it made a lot of sense for students and beginners to learn it and make it their go to editor.

Most of the comments dispute that either editor enables faster editing than the other. Several commenters noted that both editors use about the same number of keys to do any given task. There were a lot of good, interesting, and informed comments and they’re well worth reading.

For me, the most shocking, or perhaps sad, comment was from ilemming who said,

Until the Emacs development model shifts away from its exclusive focus
on super-smart nerds and starts accommodating regular coders, it is
likely to remain less popular and may struggle to introduce new
game-changing features on a regular basis.

The idea that Emacs is only for the super smart seems to me to be self-revelatory. Emacs is not, of course, a tool restricted to the “super smart” and thinking so says more about the person saying it than it does about Emacs. If you’re a developer and find Emacs, or any other editor for that matter, too hard to master, you should find another line of work.

In any event, the post and the comments are an interesting part of the never ending editor wars.

Irreal is always gathering examples of why and how Emacs can help you in your coding and writing endeavors. Regular features of those examples are Org mode, Magit, and, more recently, LSP. It wasn’t always like that. I’ve only been using Emacs for about 17 years but even I can remember not having Org or Magit.

Still, even in those prehistoric days there were plenty of reasons to use Emacs. Back in 1991, Bob Weiner wrote a paper on why you should use Emacs. A lot of the things we take for granted were not yet available. There was Dired and Gnus but the idea of Emacs as an environment you could live in was still nascent.

His paper made me realize that as nice as things like Org and Magit are, they aren’t the reason you should be using Emacs. Rather, it’s the core editing and file management capabilities that make it so useful as an editor. At the end of the day, it’s all about writing your code or prose as efficiently as possible, and Emacs excels at that.

It’s interesting to read about the reasons to use Emacs before the more recent functionalities were added. As nice as those functionalities are, Emacs is really all about efficient editing. That’s why they call it an editor.

Last week I wrote about Marcin Borkowski’s post on Emacs Everywhere, an application that lets you edit text in other applications with Emacs. As I said then, I’ve been using it for about a year but, shamefully, usually forget to invoke it.

That burning shame has motivated me to do better and I’ve been making a real effort to always use it when I have to write outside Emacs. What I’ve found is that I hardly ever write anything outside of Emacs. The two main exceptions are:

1. Responding to Irreal comments in WordPress
2. Writing texts in Apple’s iMessage

Happily, Emacs Everywhere handles both those cases beautifully. My only problem with it is that it doesn’t fill the Emacs buffer with whatever is already in the other application’s text buffer. That’s not much of a problem because I usually want to start de novo anyway. If I do need the text from the application’s text buffer, I can simply cut and paste it.

Installation is simple. Here’s my configuration:

(use-package emacs-everywhere
  :ensure t)

The harder part is getting your OS to call it when needed. The repository has some suggestions but whatever you usually use for this type of thing should work.

I’m writing about this again to encourage those who also hate writing outside of Emacs to give Emacs Everywhere a try. It works really well and, if you’re like me, will save you the stress of leaving the one true writing environment.

One of the least appreciated features of Emacs is Calc. At it’s most basic it provides an RPN calculator much like a traditional HP scientific calculator. It’s reasonably easy to learn this functionality but Calc offers much, much more. It can, for example, find the roots of functions, solve simultaneous equations, do vector operations, (symbolically) differentiate and integrate functions, and many other operations as well.

The problem is that a normal person who isn’t using Calc constantly won’t be able to remember how to invoke the appropriate commands. A little bit more than a month ago, I wrote about Charles Choi’s casual, a porcelain for Calc to help the casual user navigate the arcane Calc command language.

Choi is back with some improvements that lets us painlessly make use of some of Calc’s more advanced features. He shows you how to name a function and then operate on it by finding its roots, its derivatives, its integral, and a few other things.

I haven’t played with casual too much since I wrote about it because I already knew those elementary operations but now I can see myself using it more because I definitely haven’t committed those advanced operations to memory. Choi’s post provides some detailed examples of using those advanced features so be sure to take a look at it.

My hope is that casual will finally bring Calc to the average Emacs user. Many of those users haven’t done any Calculus since they left their university so being able to easily make those calculations with Emacs is a real advantage. We all owe Choi a vote of thanks.

Over at the Emacs subreddit, domsch1988 has an interesting question: Is it better to use key shortcuts or Meta+x? The question is not as silly as it seems. Domsch1988 acknowledges that sometimes the choice is obvious. No one, for example, is going to invoke Meta+x find-file instead of Ctrl+x Ctrl+f. Likewise, there are plenty of commands that, even if they have key shortcuts, you use so seldomly that you simply won’t remember a shortcut.

So the question is, how do you choose the best method? It’s interesting to read through the comments. One of the best pieces of advice, I think, is to use a hydra or transient to capture diverse, hard to remember commands in a menu-like interface. For example, I have a hydra for dealing with windows. All the window commands I use, even infrequently, are gathered there and can be invoked with a simple key command. If I forget the whole command, a short menu will pop up in the minibuffer to remind me. It’s a lot like which-key except that there only a few choices so I don’t have to hunt through a bunch of choices to find the command I want.

To be sure, a key shortcut is quicker but even Meta+x can be fast if you have some sort of command completion engine such as Ivy installed. It’s likely that the optimal solution is highly dependent on the user so there’s probably no “good” answer that everyone should employ.

I don’t have an overarching strategy. I simply make the choice on a case-by-case basis. What do you do?