Irreal

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.

Those of you who have been around for a while will remember Sacha Chua’s video interviews with various Emacs luminaries. Those were before the birth of her daughter and as any parent will tell you, young children can gobble up whatever discretionary time you have so it’s little wonder she hasn’t done any interviews lately.

Sadly, she hasn’t reinstituted her interviews but she does this have this offering from Emanuel Berg with an interview of Daniel Semyonov. It’s not a video and it’s a bit shorter than Sacha’s old interviews but it’s still interesting.

Semyonov is a young programmer from a remote area without a lot of resources yet he was able to bootstrap his knowledge and has contributed to several open source projects. Most recently he has worked on the Gnus backend for Atom feeds.

One of the things I liked most about the interview was Semyonov’s discussion of how Emacs and learning Elisp kickstarted his programming in general and his open source contributions in particular.

It’s a short interview and worth a couple minutes of your time. Perhaps others will share their interviews with Sacha, and she with us.