Irreal

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?

Like me, Marcin Borkowski (mbork) hates writing text in anything but Emacs. Sadly, most of us can’t live in Emacs all the time so we sometimes find ourselves having to enter text in some other application. It always ends up being painful for me. If I make a typo, I can’t correct it with a single shortcut and, most importantly, without the mouse. I don’t have completion and I can’t navigate around easily the way I do in Emacs. All of this despite the fact that on macOS you can enable many of the Emacs key bindings.

Recently, mbork discovered Emacs Everywhere. It’s an application that launches an Emacs frame and populates a buffer in it with whatever was in the text area you were in when you invoked it. You can then edit or replace that text as you see fit and when you’re done, it gets saved back to the original text area. And voilà, you’ve entered/edited text in an arbitrary application with Emacs.

I’ve been using it for about a year and really like it. I have it bound to ⌘ Cmd+F6 so it’s easy to invoke from anywhere. My only problem with it is that I forget to use it. I write thousands of words a week and only a few of those are not in Emacs so when I do have to write some text outside of Emacs, I simply forget to use Emacs Everywhere.

But don’t let my inability to remember what I’m doing stop you. Emacs Everywhere works fine on both Linux and macOS. I can’t find any evidence that it works on Windows—leave a comment if you know either way.

It’s available on MELPA so it’s easy to install. Or you can checkout its Github repository. If you like the Emacs editing experience, give it a try. You’ll be pleasantly surprised.

A few days ago, I wrote about how Evan Moses used a bit of Elisp to solve a user interface problem he was having. I liked his solution because it was simple and provided yet another example of how Emacs can adjust itself to the user rather than the other way around. Now he’s back with another example of how Emacs lets us have it our way.

This time, he wanted to number a few consecutive lines. Org mode will do that for you in code blocks, of course, but he needed a more general solution. His first thought was to use a keyboard macro with an auto-incrementing counter but he did a bit of Googling and discovered that, as usual, Emacs has us covered.

It turns out that Emacs has a command just for that. Who knew? Certainly not me. All you need to do is select the rectangle you want to number and call rectangle-number-lines. Take a look Moses’ post for the details.

It’s another example of how someone thought to provide a functionality that we didn’t even know we needed. Sadly, these things are hard to discover but sooner or later someone like Moses comes along and enlightens us.

When I wasn’t paying attention, someone decided that what Emacs really needed was Tabs¹. The next thing I knew, they were a feature of Emacs. To flog a tired meme, this brought to mind fish and bicycles. I just don’t understand it. As far as I’m concerned, fish can make better use of bicycles than I can of Tabs in Emacs.

Of course, lots of people disagree. Those people are all exclaiming, “It’s about time!” One of those people is Benjamin Leis who has embraced Tabs and even made customizations to optimize them for his workflow. He’s received a bit of pushback so he made a video to give his answers to the common objections to Tabs and to showcase his workflow.

It’s an impressive setup and if you like that sort of thing, you should take a look at the video and his configuration, which he links in the comments. You may even find yourself convinced.

I didn’t. It runs against everything I believe constitutes efficient text editing. For me, every mouse use is a cache miss. If my fingers leave the keyboard—even for the arrow keys—it feels like a failure. Leis’ workflow is perfect for someone who would really like to spend all their time in the browser. Every action involves a mouse click and you needn’t touch the keyboard unless you want to enter text. There are some—serious people like Rob Pike—who claim this is more efficient. They’re wrong.

I’ll say it again: if you take your hands off the keyboard, you’re sacrificing efficiency for… What? Using an interface designed for your Aunt Millie? The WIMP interface is fine for those who don’t code or write for a living but if you are one who does, maybe you should get serious about how you use your tools.

UPDATE [2024-04-27 Sat 11:31]: There are a lot of nice comments that discuss the benefits of Tabs and how to use them without the mouse. You should definitely look through them because they give you the other perspective on using Tabs.