Irreal

Emacs elements has another interesting video, this time on some commands that he’s rebound for quick invocation. Those commands are (roughly):

• kill-buffer
• set-mark-command (Push mark)
• set-mark-command (Pop mark)
• exchange-point-and-mark
• jump-out-of-pair (A custom command)

He begins the video with some praise for the IBM Model M keyboard that he uses. I can relate. As I’ve written before, it’s the greatest keyboard every made. It’s layout is pretty standard so whatever “standard” keyboard you’re using probably has a very similar layout.

Emacs customization, of course, is all about making it as frictionless as possible for your workflow so it makes no sense to criticize someone else’s bindings but it’s interesting how different his choices are from mine.

He uses Ctrl+1, Meta+1, and Meta+2 for some of those commands. He says re realizes that theese are prefix keys but says he never uses them. I, on the other hand, use them all the time. If I want to delete 2 words, I do it with Meta+2 Meta+d. Similarly, if I want to delete 3 characters, it’s Ctrl+3 Ctrl+d. These are all burned into my muscle memory and I’d never give them up.

There’s more to his customization than just rebinding the keys. Most of the above commands also activate the mark and result in highlighting regions. That’s almost never what I want and neither does he. He has a bit of custom code to deactivate the mark so that doesn’t happen. Even if, like me, you don’t care for his rebindings, you may want to grab his code to eliminate the mark activation.

This is a short video and worth a few minutes of your time.

All of us Emacs nerds are familiar with Neal Stephenon’s essay In the Beginning…Was the Command Line, in which he describes Emacs as the thermonuclear word processor. A couple of years ago, he did a podcast with Lex Fridman in which he expands on his remarks and comments on the longevity of Emacs.

Fridman asked him if he thought that Emacs would still be around in, say, a hundred years. Stephenon’s answer invoked the John Henry legend where in the end, Henry was unable to keep up with the steam hammer. Stephenson says that Microsoft and Apple are pouring so much money and effort into VS Code and XCode that eventually Emacs won’t be able to keep up.

I don’t think that XCode is an issue in this discussion. It’s not primarily a text editor and is, in any even, very specific to the Apple universe. VS Code, on the other hand, can certainly be said to be an Emacs competitor. I don’t think it’s as powerful or full featured as Emacs but it does have a lot of money and power behind it. Whether Microsoft itself will survive for a hundred years and if they do whether they’ll find it economically advantageous to continue supporting VS Code are open questions.

I think that technology 100 years from now will look so different from what we have today that virtually no technology we have now will be extant. That will probably include Emacs. On the other hand, Emacs has been defying the odds for a long time and may surprise us all. What do you think?

Arialdo Martini is back with a very informative post about using registers to store buffer locations and other data. He starts with positing the need to store buffer locations by name rather than storing them in a ring buffer as he discussed in his post on the mark ring and then gives two possible implementations.

Of course, that’s not necessary because Emacs already has functions to do this. I generally use registers to store other information such as window configurations and text I need to insert repeatedly into a document but storing buffer locations can be useful.

It turns out that the Emacs implementation is much more robust than you might imagine. For example, if you close a buffer that is stored in a register and is displaying a file, Emacs will update the register to a file-query that will reload the buffer if you jump to the register containing the reference.

But it gets better. Martini shows how you can make registers persist across Emacs sessions. All of this is builtin to Emacs and available simply by invoking the requisite functions.

The only thing that Martini doesn’t mention is that the register keys aren’t stored as a single character but as a symbol reference.That means that you can name a register as a symbol (in Elisp), which makes it easy to store, say, window configurations without risking having it overwritten interactively. I use this all the time to run certain functions in full screen and then restore the previous window configuration when I’m done.

The thing about registers, as Martini says, is that they’re implemented using normal Elisp data structures that are available to end users to use in any way they see fit. It’s another example of how configurable Emacs is.

This post is about another of my browsers tabs that I’ve had open seemingly forever. It’s a curated list of resources for writing with Emacs. As such, it’s a nice coda to my previous post on Emacs writing workflows.

It’s mostly a list of tips and how-tos rather than links to tools. Many of the links point to things that Irreal has covered before but there are plenty that are new to Irreal.

There are sublists for writing blogs, technical documents, screen plays, and books. There are also links for writing workflows and Emacs modes and configurations for writers. If you’re a writer, there’s a lot of good material on this site worth perusing and you should probably bookmark it for easy reference.

This site is a good demonstration of the fact that Emacs, as an editor, is useful for much more than just writing code. Lots of people, me included, use it for virtually everything we write. The same things that make it so good for editing text also make it ideal for writing prose or text of any kind. As I’ve said before, every time I write in something other than Emacs, I feel like I’m in Bizarro World where nothing works as it should.

I’ve written before about Peter Prevos and his Emacs Writing Studio but here’s a bit more. I’ve had this article about the Emacs writing workflow up in my browser for a long while and decided the time had come to either write about it or delete the tab.

Prevos views writing as a five step process:

Ingestion

Reading, listening to, or watching content as a source of ideas. Emacs, of course, has extensive support for this.

Ideation

This stage involves taking notes about the content from the ingestion step. Emacs has exceptionally strong support for this with the Org package as well as other packages, such as Denote and Org Roam, to help you organize your notes. Prevos uses five types of notes that you can read about in his article.

Production

This is the step where you write your post, article, book, or whatever. It is, I think, the most enjoyable part of the process. Again, Emacs has our backs for this step. Unless you have special requirements, you almost certainly want to write your text in Org mode. The Org markup makes it easy to apply almost any formatting you’re apt to need for a writing project and the export system lets you deliver the final product in almost any format.

Publication

This is where you produce the final product. It could be a simple post, a longer magazine or journal article, or a even book. If you wrote in Org mode, you can produce a product suitable for any or all of these with the push of a button.

Communication

In this step, you tell the world about your product. Emacs has support for email, IRC, social media and other ways of communicating from inside the editor.

If you produce written output, you’ll probably recognize most of these steps even if you don’t follow Prevos’ workflow exactly. I use something vaguely resembling the first four steps but don’t do anything about communicating my daily Irreal output.

Prevos notes that his workflow is his workflow and others most likely do something different. Still, there’s some good ideas in his article that any writer can adapt for their own use.