Irreal

Back in 2020, I wrote a post about the New York Times Spelling Bee puzzle. The TL;DR is that you’re given a list of seven letters, one of which is special. Solving the puzzle involves finding as many words as possible using the letters, possibly repeated. Longer words score higher and using the special letter gives you a bonus.

I didn’t have time to search for all the words but I did like to find the pangrams: words using all seven letters. I could usually do that fairly easily but I hated puzzles where I couldn’t find any pangram. So naturally I invoked my inner nerd and wrote some Elisp to find them. You can check the above post for the details.

In the meantime, the Times had stopped sending me the puzzle so I’d pretty much forgotten about it. Now Bill Mill has revisited the puzzle. He was interested in finding any pangrams that would get you to the highest scoring level all by itself. Unfortunately, he didn’t have enough information to solve that problem so he he decided to find the lowest scoring pangram instead. He wrote some Python to solve that problem. You can read all about it in his post.

Later, he discovered some of the missing information he needed to solve the original problem and wrote another post about it. Amusingly, with the new information it turns out that the worst—i.e. the lowest scoring—pangram is “fuckwit” but he was also able to find the best scoring pangrams. See Mill’s posts for the details.

None of this matters at all, of course, but it is fun to see how Emacs and Elisp (or in Mill’s case, Python) can be brought to bear to investigate the problem.

I really like Gnuplot. It can produce most of the types of graphs that you’d actually want to produce and it’s reasonably flexible. That said, I hardly ever use it. It’s sort of a chicken/egg problem: on the one hand, I don’t use gnuplot very often because I can’t remember how to use its (semi-arcane) command language. On the other hand, I can’t remember the language because I seldom use it.

I just ran across a very short video from Anand Tamariya that shows the user selecting a rectangle of data, calling gnuplot-rectangle, and having a graph of the data be rendered by gnuplot. The video is only 35 seconds and doesn’t have any explanation. I was bitterly disappointed because it seemed like an easy way to use gnuplot for many of the cases I care about.

Serendipitously, I had another tab open in my browser by the author of the video that showed the code for gnuplot-rectangle and explained how to use it. There’s not much to do. You have to have gnuplot installed on your system, of course, and you also need to have the Emacs gnuplot package installed. That package is available from the Melpa and NonGNU elpa repositories so it’s easy to install. If you’re like me, you probably already have them installed.

The final piece is the gnuplot-rectangle function that Tamariya gives in his explanatory post. I haven’t had a chance to try it yet but it seems just perfect for folks like me that don’t need to draw graphs often enough to learn the intricacies of gnuplot.

Arialdo Martini has a very informative post about the Emacs mark ring and how it works. On the surface, it’s pretty simple. The mark ring is a ring buffer that records positions inside a buffer—or several buffers in the case of the global mark ring—and allows you to return to or otherwise use those positions.

When you dig a little deeper, you find that there’s a lot more to it. For example, the mark helps define a region in an Emacs buffer and that fact can be leveraged to perform all sorts of useful tasks.

The mark ring actually stores markers to a given position so they are automatically adjusted if the absolute position of a place changes. Thus, you can, for example, push a position onto the mark ring, add text above that position, and still jump to where the mark was set even though its absolute position has moved.

In addition to allowing you to push positions onto the mark ring, Emacs will also record positions for you. For example, if you jump to a new position, your old position is pushed onto the mark ring. That allows you to do things like search for a symbol and then jump back to where you started. The exact rules for when Emacs pushes the mark onto the mark ring or global mark ring are a bit complex. This Irreal post discusses a video the explains some of those complexities.

The simple mark ring mechanism enables all sorts of useful functionality. Take a look at Martini’s post for some examples.

Those of you who have been reading Irreal for a while know that I’m a huge fan of Emacs Calc. It’s tremendously flexible and comprehensive and it’s built into Emacs. But that comprehensiveness comes at a price: it’s very hard to learn its commands and they always prove evanescent if you don’t use them regularly. I’ve been through the manual a couple times and I still can’t remember how to use most of Calc. I almost always bring up the cheat sheet when I need to do anything more than the basic calculator functions.

Charles Choi to the rescue. We haven’t heard from Choi for a while and now we know why. He’s been busy building a porcelain for Emacs Calc. It’s a transient menu that helps you remember many of the esoteric Calc commands. When you get stuck, you can bring up the menu and navigate your way to the proper command.

Choi says that he’s not trying to provide full coverage of the Calc commands, just the most—for some value of “most”—used commands. You can read about his goals and non-goals at his post.

The package is on MELPA and although Choi doesn’t give the use-package recipe for installing it, here’s what I used:

(use-package casual
  :ensure t
  :bind (:map calc-mode-map ("C-o" . 'casual-main-menu)))

I just installed it so I don’t have a lot of experience with it yet but so far I really like it. The menu doesn’t appear until you invoke it and it disappears after you choose a command so it doesn’t get in the way. I can see this package making Calc more approachable and increasing its usage. If you’re a Calc user or would like to be, you definitely want to take a look at Choi’s post.

Protesilaos Stavrou (Prot) has published an excerpt from a conversation he had with someone asking his advice on Emacs and note taking. The TL;DR is that his correspondent is a Vim user who is considering changing to Emacs for the advantages it offers for note taking. He is asking Prot how to proceed.

Prot’s advice is eminently sensible: Start slow. Use Org mode to begin with and add other packages only when you find you need them. Specifically, he advises using a single notes.org file with a heading for each note. Each note can have, or accumulate, additional subheadings as required. He also recommends setting the file to open with only the headings displayed. Folding is one of the strengths of Org mode and helps keep you from being overwhelmed by the available information.

His best advice—in my opinion—is to concentrate on the notes themselves rather than on the mechanics of taking them. He encourages note takers to spend time on writing purposeful and coherent prose so that when you read them later you will understand what they’re about and what your thinking was at the time. He also suggest linking new notes with previous notes where it makes sense. That, of course, is the basis of the Zettelkasten method, which Prot says he hasn’t studied and doesn’t necessarily recommend unless you, too, are genius workaholic like Niklas Luhmann. Better, he says, to start slow and find a system that works for you.

If you take notes, in Emacs or elsewhere, you should definitely take a look at Prot’s post. It has a lot of good advice without insisting that you use a particular piece of software.

Marcin Borkowski has a nice post on Emacs’ follow mode. I’ve known about follow mode for a long time but never saw the point of it. That’s because I always thought of it as being used only on prose buffers. But as Borkowski points out, it’s really useful for code buffers where you want to see all or most of a large (or, perhaps more than one) function. By using follow mode you get two side-by-side windows that act as a single large window as far as scrolling is concerned.

When you scroll one window, the other scrolls too just as if they were a single window. This effectively doubles the height of your screen. But it gets better.

If you have enough horizontal real estate, you can split a window into not just two but three (or more) windows and link them together with follow mode so that they act as a single window tripling (or more) the height of you screen.

As I said at the top, I’ve never run across a case where doing this for a prose buffer was worth the effort of invoking follow mode but I agree with Borkowski that it can be useful for code buffers where surrounding context can be critical. Now that my eyes have been opened, perhaps I’ll make follow mode a part of my everyday toolkit.

If you aren’t already a follow mode user, take a look at Borkowski’s post. It’s reasonably short and you’ll learn some things that may be useful for your own workflow.

I’ve written before about messing around with Emacs defaults. The argument from those favoring changes is that Emacs’ conventions are not congruent with modern day standards and thus confuse n00bs. This, is turn, inhibits Emacs uptake by new users.

The other side of the argument is that long term users should not have their workflows and muscle memory disrupted on the nebulous basis that changing the default may result in new users. After all, most of those long term users learned Emacs long after today’s CUA standards were in place and can be forgiven for expecting others to do the same.

It’s not that the needs and expectations of new users should be ignored. It’s just that the way to accommodate them is not as easy as some claim. Some of the problems are discussed in the above post and some suggestions for addressing them are in the comments.

In the mean time, here’s a small rant from the Emacs Elements guy. He points out, correctly, that if you don’t like the Emacs defaults, you’re free to change them—indeed, that’s the whole point of Emacs configurability—just don’t insist that everybody else should change them too to suit your preferences. Sadly, the majority of comments to the rant are of the type that insist all those troglodytes from the PDP-10 era need to get on board with the new VS Code compliant conventions. The fact that those troglodytes can edit rings around them and their VS Code seems to escape them.

On the plus side, some of the comments suggest ways of addressing the problem. While I have limited sympathy for the whining complaining that “the defaults aren’t what I’m used to”, I’m glad to see other folks embracing the Tao of Emacs and suggesting ways of adapting Emacs to the problem.

This is just a short PSA. As most of you know, I’m a huge fan of Mu/Mu4e and use it as my main mail client. Lately, I’ve wimped out and rather than building it from source, I’ve been installing it from Homebrew. That’s mainly because building it requires Cmake and some other tools that I have no other use for.

I’d been using the 1.10 version, which, sadly, had a few problems. Mostly it lost the marks of previously read emails when a new one came in before the mail listing buffer had been dismissed. Happily, that problem has gone away with version 1.12 and it now seems perfect. You can also choose whether emails should display as straight text or if links and images should be active. The default Homebrew install is now 1.12.1 so it’s easy to upgrade.

If you’re still running an older version, I strongly recommend that you upgrade. I’m sure you’ll be as pleased as I am.