Irreal

Over at the Emacs subreddit, Available-Inside1426 asks why there isn’t an Emacs 2. By that he means a rewrite of Emacs to address what he sees as problems with Emacs. Those problems include the usual silliness like a better GUI implementation, better mouse support, a client-server architecture, and so on. The only improvement he suggests that makes sense to me is implementing threads.

Of course, everyone would like Emacs to have a robust thread implementation but the problems are legion. Here’s an account of one brave soul’s attempt to implement them. The TL;DR is that in the end he gave up because there’s just too much shared state built into Emacs.

One thing you hear all the time and that Available-Inside1426 repeats is that “Emacs was made for a different world”. I don’t know what that means. Sure, Emacs was made in a different world but I don’t think it’s true that it was made for a different world. After all, it was made to edit text as efficiently as possible and in that it still performs better than any other editor. My cynical suspicion is that what “made for another world” really means is that it doesn’t have enough bling, and is not centered on point and click.

Emacs development is, in fact, proceeding apace and everyone with even a bit of software development experience knows that rewriting a mature system always ends in tears. Emacs doesn’t need to be rewritten. Sure, some things would benefit from improvement but that exact process is always underway. Your pet wish may not be as high on the list as you’d like but if it’s worthwhile, it will certainly be implemented eventually. Who knows? Maybe we’ll even get a good thread model.

Philippe Gaultier has an interesting post on making a table of project dependencies. He’s using Rust, for which there is a tool to produce a tab-delimited (TSV) file of dependencies. The problem, for Gaultier, is that the output is not very human readable.

His solution was to write an AWK script that converts the TSV file to a version of Markdown and then export that to HTML. It works well and produces nice output that he can share with his coworkers. Take a look at his post to see the results.

Not to be that guy but when I read his post I thought, “Gee, that seems like a lot of work. How would I do that in Emacs?” After a few moments thought, I realized that I was already doing exactly that. I have a TSV file that I export from my iPhone and want to turn into an Org table. I simple paste the TSV data into my file and call (org-table-create-or-convert-from-region '(16)) to reformat the data to Org-mode table format.

The '(16) parameter tells org-table-create-or-covert-from-region that the data is tab delimited. There are other possible delimiters, see the documentation for the details.

Again, not to be that guy but this is another example of how powerful and flexible Emacs is. Have some data you want to convert? Chances are Emacs already has a way of doing it. Even if it doesn’t, it’s generally pretty easy to add a bit of Elisp to do it. The worst case is you’ll have to write an external app—in AWK, or whatever—to convert the data in your Emacs buffer to the format you need. Regardless, the whole process can be handled without leaving Emacs.

Marcin Borkowski (mbork) has an excellent post concerning a function I didn’t know about. It helps with the following problem: suppose you have a function with several implementations, want to access them with a single function name, and need to choose the implementation to use when you invoke the common function name.

That probably seems a little obscure but the example that mbork gives makes it clear. His use case is wanting to play some music using one of mplayer, vlc, or mpv using a single invocation name.

There are plenty of straightforward ways of doing this, of course, but mbork shows a very nice builtin method: define-alternatives. It’s easy to use and set up. You simply provide an alist of method/function pairs and use define-alternatives to specify a function name that will invoke the method of the user’s choice. See mborks post or the documentation for the details.

Define-alternatives is a great way of handling this situation. It’s hard to imagine a method that requires less code or effort on the developer’s part. As mbork says, the method doesn’t seem to be well known so it’s worthwhile pointing to mbork’s post as a way of getting the word out.

Over at the Emacs subreddit, FirmSupermarket6933 asks who really created Emacs. He cites various sources claiming that RMS did or did not create it. Is he responsible only for GNU Emacs or was he there from the beginning? Sadly the commenters purporting to answer his question have no more idea than FirmSupermarket6933 about the editor’s origin.

All of this was long ago and far away but almost everyone who has a reasonable grasp of Emacs’ history agree on some basic facts:

• Emacs began circa 1976 as a set of macros for the TECO editor. That’s where the macs in “Emacs” comes from. The origin of the E is more controversial. Some say it stands for “Editing” but Stallman and others say it was chosen for more pragmatic reasons.
• Stallman was heavily involved from the beginning. Guy Steele has produced some email threads that show this definitively.
• Many others including Steele, David Moon, and James Gosling were instrumental in moving the effort forward. The end of this process is what we now know as GNU Emacs

Even the original effort was more curation than invention. The original TECO macros were collected from the macros that people in the AI Lab were using. The idea was to have a standard set of macros that everyone could use. Even so, there was a surprising amount of work to get everything working. See Steele’s email threads for the details.

All of this began almost 50 years ago so memories are dim and, sadly, many of the principals are nearing the end of their lives so it’s important to get these facts right while we can.