Irreal

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.

I just came across a really interesting post from Tory Anderson. Like me, Anderson lives in Emacs. In fact, since he’s a Linux user and runs exwm, he lives in Emacs even more than I do. Anderson notes that sometime Emacs crashes or freezes and has to be restarted. We’ve probably all experienced this. It doesn’t happen very often to me but it does happen. I’m pretty conservative about Emacs and don’t run unreleased versions. Lots of people do, though, and they probably have more crashes and hangs than I do.

In any event, the question is what do you do about recovering files that were open and unsaved when the editor died? Emacs, of course, has us covered. The recover-file command lets you recover (most of) what was in the buffer when Emacs died. It gets that information from the auto save file for that buffer, which is why it may not have everything.

The problem is, you have to remember which files to recover. Anderson says he did this by going through his error log. It turns out, though, that Emacs has us covered here too. You can run the command recover-session and it will present you with a list of every session’s saved data that it knows about. You pick the one you’re interested—usually the most recent one—and then run recover-session-finish (bound to Ctrl+c Ctrl+c) and Emacs will query you for each file it knows about in that session and ask you if you want to recover it.

Anderson describes a slightly different process involving only recover-session-final that didn’t work for me so be sure to read the documentation too.

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.