Irreal

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.

I’ve noticed that a lot of people treat their editor like a car. Some people like to have more than one and others feel like they should trade them in every couple years. I don’t understand either group but especially not the second.

I understand the need to replace an editor that’s not meeting your needs, of course. That’s not what I’m talking about. I’m talking about those folks who are always chasing the new and shiny. Perhaps they’re motivated by FOMO; I don’t know because, as I said, I don’t understand it.

One such person wrote to Protesilaos Stavrou (Prot) saying that even though he loved Emacs and its community, he wondered if he should move to Neovim. The reasons he gave for the prospective move was that Neovim was maybe a bit faster and (like Emacs) had a strong user community. Perhaps, he said, Lua/Neovim was the “right side” to be on. That seems to me to be a bit like being buffeted by an unceasing wind as in the second circle of hell (and for the same reason).

Regardless, Prot’s answer is a beautiful and well reasoned exegesis of why he came to Emacs and why he stays here. There are several aspects to his answer but the two main ones are:

• Emacs represents a real, not hypothetical, freedom to it users
• Emacs provides a unified user interface for all of the tools you use.

Take a look at Prot’s post for the details. It’s not long and will ensure you that you’ve made the right decision by choosing Emacs and will make you happy that you made that decision.

Marcin Borkowski (mbork) has a nifty post that discusses a handy Emacs facility that I didn’t know about. A few weeks ago he wrote about follow mode. It was a good post that opened my eyes about the real utility of follow mode and I wrote about it here. This post is about a similar facility called next-error-follow-minor-mode.

The idea is that if you’re in a buffer that references places in another file—think occur buffers, for example—you can turn on next-error-follow-minor-mode and as you move around in the buffer the other buffer will automatically jump to the matching place.

My workflow has a couple of places where I regularly use occur buffers and next-error-follow-minor-mode seems like a real win because my workflow involves jumping from an occur buffer item to the corresponding place in the other buffer.

If you’re in a buffer that supports next-error-follow-minor-mode, you can enable it with the shortcut Ctrl+c Ctrl+f.

It’s another one of those obscure Emacs facilities that are hard to discover but once you do you wonder how you ever lived without them.

Another quickie today. Evan Moses has a short post that shows how he solved a problem particular to his workflow. He’s an Evil user, which means that when he wants to save a buffer he types :w. Unfortunately, he’s prone to fat fingering that command and types :w2 instead. That writes the buffer to a file named “2” instead of the file that the buffer is visiting.

We can all relate. Most of us have some sort of similar mistyping that we’re prone to make. But this is Emacs and it’s infinitely configurable so Moses decided to save himself further grief by writing a bit of Elisp.

He simply wrote a function to check whether or not the argument to evil-write is 2. If it is, the function asks if he really wants to save to a file named 2. The function returns the result of that question.

Then he advised evil-write to run his function before writing and to abort the write if the function returns nil. You can check out the code in his post. It’s simple and exactly what you’d expect.

I’m writing about this not because I think many people are fat fingering w as w2 but because it’s another example of how Emacs’ unsurpassed configurability lets you fix small but annoying problems. Notice how simple the solution is. You don’t have to rewrite the evil-write function. You just tell Emacs to run your function first so that it can ask if saving to the file 2 is what you really want.

Charles Choi has been writing a lot of Elisp lately and being a scrupulous developer, is careful to write informative and useful docstrings. Being conscientious, he’s careful to check the formatting of his docstrings by calling describe-function. That sounds simple enough but, as Choi, says, it’s actually a pain involving several steps and moving around in the text of the function.

Of course, being a programmer, Choi decided to automate the process. That’s a win because it makes it easier to (repeatedly) check the docstring resulting in better documentation for the end user.

Another issue that Choi addresses is the number spaces at the end of a sentence. That, of course, is a minefield and whatever you do is sure to offend someone. But a good case can be made that since docstrings are almost always displayed in a monospaced font, there should be two spaces at the end of a sentence.

There are some problems though. Fill-paragraph won’t enforce the value of sentence-end-double-space if sentences end with a single space. As usual, Emacs has us covered. Instead of just calling fill-paragraph you can first call repunctuate-sentences. That will add two spaces after each sentence, which is just what you want in these circumstances. Take a look at Choi’s post for the details.

Docstrings seem like a small thing but done right, they can be very useful. Choi’s post demonstrates some ways to make writing them a bit easier.

It’s a commonplace in the Emacs community that you never stop learning Emacs. No matter how long you’ve been using it, there’s always something new to discover. The truth of that maxim was brought home to me today when I came across an Emacs subreddit post from rvc09 asking how he could run a predetermined set of commands in Eshell as with a script in other shells.

I’ve never needed to do that so I hadn’t thought about how I would go about it. It turns out that the answer is simple but not at all obvious. Scroot had the answer. It turns out that you can define an Elisp function eshell/some-command and run it in Eshell by calling some-command.

But wait, there’s more. Within such a function you can use eshell-command¹ to call any Eshell command. Those two facts allow you to essentially define a script that you can run from within Eshell.

As I said, I had no idea about this. It’s just another point on the never ending arc of my Emacs journey of discovery.