Irreal

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.

Most Emacs users who are at all familiar with Elisp know that you have to specify the interactive command for functions if you want them to be interactive—that is, if you want them to be callable with Meta+x. Most of those people also know that you can use the interactive command to prompt a user for function parameters.

What is less well known is that you can also pass a list of parameters for the function in the interactive command. By itself, that’s not too useful, of course, but rather than specifying a list, you can specify a function that returns a list. The function can do anything as long as it returns a list. Arialdo Martini has a post that illustrates this nicely.

He looks at the problem of surrounding a region with a pair of delimiters. The question is how to get the two delimiters. The most obvious—but also most difficult—solution is to simply add code to the body of the function to prompt for the delimiters. It’s far easier to use the interactive command to get them and this also has the advantage of allowing the function to be called from Elisp without any prompting.

But what happens if you want to limit the choices to a predetermined set? That’s exactly what completing-read is for. Sadly, there’s no interactive parameter for this but you can write a function that uses completing-read and returns the delimiters as a list.

Martini’s post uses this idea to implement a set of functions that surrounds a region with any of a predetermined set of delimiters. As Martini says, there’s already plenty of functions and packages that do this. The point of his post is to explore how you can use the interactive command to pass parameters to a function. It’s a good post and worth a few minutes of your time to read.

I’ve just had another of my occasional workflow epiphanies where I suddenly realize that some tedious routine task I regularly perform could easily be automated. In this case, only partially automated but one step at a time.

Everyday, I take a measurement and record the result in a notebook¹. Every other Sunday I copy the measurements from my notebook into a file. I’ve been maintaining that file since before I started using Emacs so it doesn’t follow the conventions that I use now. In particular, each entry has a date with the format mm/dd/yy.

It’s really a pain to enter those dates. I realized that I could easily use a macro to enter them. My idea was to put the dd value in a macro counter and let the macro increment it for me for each new entry. Here’s my new procedure:

• I use Ctrl+x Ctrl+k Ctrl+f to set the counter format to %02d so that each dd entry will be exactly two digits.
• I use Ctrl+x Ctrl+k Ctrl+c to set the counter to the day number of the first entry’s date.
• I define the macro by pressing F3 mm/ Ctrl+x Ctrl+k Ctrl+i to enter the day number, and then finish the macro with /yy F4.

It seems like a small thing but it really makes entering the data easier. Of course, what I actually thought was that I should write a function to do the date automatically but dealing with dates is a pain and what’s really needed here is a closure so that subsequent dates can be returned. That’s possible and I may do it eventually, but in the meantime, the macro is a big improvement.

Afternote

After I wrote this, Marcin Borkowski wrote a nice post on using keyboard macros that reminded me that you can use F3 instead of Ctrl+x Ctrl+k Ctrl+i to insert the counter value. I use counters in keyboard macros so seldomly that I’d forgotten that.

Arthur A. Gleckler has a nifty post that discusses Emacs narrowing as a way to help with focus. The TL;DR is that sometimes you want to focus on a piece of code or other text and one way to do that is to temporarily remove all the surrounding text so that only the part you’re interested in is visible.

Emacs, of course, has you covered. It’s narrowing functions are just what’s called for. You can narrow to a region, a function, and various other parts of text. To a first approximation, it’s just what you need.

Gleckler, though, has an additional requirement. Sometimes he wants to look at the surrounding context and then return to the narrowed display. It’s easy, of course, to just widen the text, look at the context, and then narrow it again but that’s “complicated” enough that you can loose focus. He wanted a way to quickly pop in and out of narrowed displays.

He solved that problem with a bit of Elisp. The basic idea is that if there is an active region, he records the position of the region as an overlay with a special property and narrows to it. If no region is active, he looks for an overlay with the special property and uses its position as the inputs to narrow. Finally he binds a key shortcut to his function so that invoking it is as simple as it’s possible to be in Emacs.

The code is only a few lines and pretty easy to understand. If you’re interested in a similar facility or just want to see how he handled remembering which text to narrow to, take a look at his post. It’s short and easy to read.