Irreal

Around a month ago, I wrote about Charles Choi’s post on Tuning Emacs to Write Prose in Org and Markdown. One of his suggestions was to use proportional fonts when you’re writing prose. He claimed it’s easier to read and less distracting while you’re writing.

I wasn’t exactly dismissive of this suggestion but it’s fair to say that I was skeptical. After all, I’ve written two books and close to 5,000 Irreal posts all in a monospaced font using one markup language or another. Nevertheless, I decided to try it out for a while starting with that original post commenting of Choi’s.

I found that I actually did like it for writing prose but I didn’t want all my Org buffers rendered with a proportional font. I already had a bit of Elisp to set up my blog post buffers so I just added some code to toggle on variable-pitch-mode. Then I thought that I should really do this with directory local variables so I put a .dir-locals.el file in my blog directory but I got maximum lisp evaluation depth exceeded errors.

This has happened to me before when I tried to use directory local variables with the eval keyword and after messing around with max-lisp-eval-depth without success, I finally gave up and returned to my Elisp hack.

In any event, I’ve now officially adopted proportional fonts as my standard for writing prose. It turns out Choi was right all along.

I’ve never been a fan of Emacs starter packages. That’s probably because when I started, there weren’t any: you simply rolled your own configuration using whatever resources you could find. Still, there’s something to be said for a minimal configuration that can get you up and running until you learn more about what’s possible and what Emacs offers.

Ashton Wiersdorf has a solution: Emacs Bedrock. The idea is to offer an absolutely minimal configuration that relies almost entirely on built-in packages. The only third-party package that the default configuration includes is which-key, a wonderful package that offers you help on completing a key sequence if you stop part of the way through. I use it all the time and wouldn’t want to live without it. It’s perfect for the n00b trying to learn the Emacs key sequences.

It’s easy for those of us with highly tuned configurations that include multiple third-party packages to forget that vanilla Emacs offers a powerful and very useful editor. I spent some time with an unadorned Emacs when I started and added packages only when my workflow demanded it.

Wiersdorf has that covered as well. There’s a second configuration file that offers some Emacs “enhancements”. These include such things as the irreplaceable Avy, and the world’s best Git porcelain, Magit. The Minions will, of course, be exercised that his default theme is dark mode but, again, these things are easily configured and explained. For example, the configuration points to modus-operandi for a corresponding light theme.

You can checkout the actual configuration here if you’re experienced but if you’re a n00b, simply follow his directions to install a trial installation and see what you think. If you like it, you can copy the trial configuration into ~/.emacs.d to make it permanent.

This is, I think, a good way to get started with Emacs.

Just a quickie today. Emacs Elements has a YouTube short in which he offers an Emacs tip on adding newlines to the bottom of a buffer. The idea is that you can configure Emacs so that when you type Ctrl+n at the end of a buffer, it will create a new line without the need to go to the end of the last line and type Return. The video is less than 40 seconds so there will be no problem fitting it in.

This is the type of thing that would get me into trouble in no time at all so I won’t be enabling it but if this seems like something that make sense for your workflow, take a look at the video. It’s built in so there’s nothing to install. You can turn it on and if you don’t like it, turn it off again all in the same session.

Over at LWN.net, Jake Edge has a book review of Mickey Peterson’s excellent Mastering Emacs. Edge is a long time Emacs user who never got around to really mastering the editor. Through a long process starting with a fascination with Lisp, Edge became determined to learn more about Emacs. Part of that journey involved finding and reading Mastering Emacs.

Edge notes that the book takes a long time to get to actually editing text. Rather, it spends time nailing down the terminology and philosophy behind Emacs. He says, and I agree, that that was an excellent approach. As he says, Peterson approaches the material in a way that make sense for a narrative rather than a reference. He also says that although the organization of the book may seem a bit strange at first, the key to understanding it and Emacs is to recognize that Emacs is a tinkerer’s editor.

When he got to the editing part of the book, Edge discovered that actions in Emacs are subtly different from other editors. For example, when you “kill” text you don’t delete it, you merely move it to the kill ring. That means it available for reinsertion elsewhere, where “elsewhere” means some place in the same buffer or even in another buffer. In fact, with the proper configuration, you can even insert it into a completely separate application.

Another interesting part of the post is the comments. Other than a long, silly, and ultimately pointless argument over whether the book is somehow evil for not being “free”, they tell the story of how other users came to know and champion Emacs.

If, like me, you enjoy other people’s Emacs stories, this is a nice article. And, as I say, the comments are worth a bit of time too.

Christian Tietze has a, for me, provocative post on the Emacs 29.1 kill-buffer prompt. I am a stickler for accuracy and consistency: just ask my family that has to endure my rants about inconsistencies between episodes of TV series. Tietze makes me look like an amateur.

His post laments the change in the kill-buffer prompt in Emacs 29.1. It used to be something like “Buffer modified; kill anyway? Yes or No”. Emacs 29.1 added a third option: “Save and then kill”. His problem is that the “Yes” or “No” answers are now ambiguous. At least as far as his muscle memory is concerned.

Tietze advised the kill-buffer--possibly-save function to change the prompts to:

• Save and kill buffer
• Discard and kill buffer without saving
• Cancel. Exit without doing anything

These prompts have the advantage of being consistent and clear. Still, almost all of us won’t care. We may grump that the prompt lacks consistency but we’ll adapt. Tietze is different and fixed things to be more rational.

The point of this Irreal post is that Tietze’s post is an allegory on the ability of Emacs to let you have it your way. Tietze could have just sucked it up and dealt with the new prompts or he could have filed a complaint to, say, Emacs-devel and hoped that he wouldn’t be ignored. Instead, he simply fixed it in his own environment and wrote about it in case others or the Emacs developers wanted to do likewise.

To me, this represents the best about free software. Not only do we have the source code but it is, in fact, easy to modify Emacs’ behavior without recompiling the app. I don’t know of any other app with this level of adaptability.

Over at the Emacs Elements Channel there’s an excellent video on Hippie Expand, The main problem with Hippie Expand is its name. It gives you no clue as to what it does or why you might want to use it. The TL;DR is that Hippie Expand will try a sequence of completion methods until you find the correct one. It is, in that way, better than any individual completion method.

Being Emacs, it is, of course, configurable. You can specify what completion methods to try and in what order to try them. There is, really, no reason to use any other method. Even if you have some method that Hippie Expand doesn’t use, you can simply add it to the list of methods that Hippie Expand uses. I long ago tweaked the order of the methods but I no longer remember why.

Hippie Expand can be a little confusing because some of the methods may offer more than one completion. In that case, subsequent invocations will offer those completions before moving on to the next method. That’s exactly the behavior you want, of course.

The video demonstrates how to jump to a particular completion method in the list. You have to know the method’s position in the list to use that so it’s not as useful as you might think. All in all though, Hippie Expand is a very useful method that’s worth knowing about.

The video is 12 minutes, 51 seconds so plan accordingly. It’s a good video and a real help in understanding what Hippie Expand does and why you should be using it. It’s definitely worth your time to watch it.

After watching and writing about Prot’s video on custom mode lines I’ve been experiencing a vague urge to customize my own. Adding to that urge has been a couple of posts by James Dyer who has also felt the urge. The first used Prot’s post as a jumping off point for his own customization. Now Dyer is back with his latest iteration.

Dyer has a list of goals for his ideal mode line. The ones that resonate with me are:

• Show the full path name. I often wish for this, not for the same reason as Dyer but because I occasionally start a post in ~/org/ rather than ~/org/blog/ and having the full path name would help me realize this earlier.
• A Clear indication of file modification. That’s not usually a problem for me but the three side-by-side indicators can be confusing if one other than the modified indicator is lit.
• Efficient information display. Unlike Prot, Dyer and I like to have as much information as possible displayed. We both want the row and column of the point displayed, and would like at least the important minor modes indicated.

Dyer includes the code for his mode line configuration. To really understand it you should watch Prot’s video. Perhaps you, too, will feel the urge for a bit of mode line customization.

UPDATE [2023-09-11 Mon 11:41]: Added link to second Dyer post.

Álvaro Ramírez has extended his extensions to the Emacs 29 Sqlite mode. I no longer have to interact with SQL databases for work but these days seemingly every application uses an sqlite database. Why not? Sqlite databases don’t require a heavy weight database. They’re just local files accessed with a simple, robust library that allows the access and modification of the database with the SQL language.

Emacs 29 has an sql-mode that allows minimal interaction with an sqlite database. Ramírez has extended those capabilities in a useful way. Take a look at his post and animated gifs to see what you can do.

He says that the code is still experimental but if you need to work with sqlite databases, it may be just what you need. The code is available on GitHub and is a single relatively short file so it would be easy to added it to your configuration and try it out. If you need to interact with sqlite databases, you should definitely take a look at Ramírez’s post.