Irreal

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.

Charles Choi has a new announcement about his Casual package. Several of his users encouraged him to offer Casual to Emacs core or Elpa. He did that and, of course, he got push back. The main complaint was that there were too many apps.

I’ve always felt that having separately installable apps was an advantage. Others disagree and so Choi has implemented a new package that includes all the casual apps and has announced that he will remove the current apps from MELPA shortly. Take a look at Chou’s post for the details.

I don’t understand why any of this is necessary. The purists insist that MELPA is an illegitimate repository because … reasons. But the truth is that almost every popular Emacs package is curated there and that for all intents and purposes, MELPA is Elpa. I would have been happier if Casual had remained on MELPA and the various apps had remained separately installable.

Regardless, if you like the Casual apps—and there’s a lot to like—you will need to take action to update your configuration. Perhaps the Casual apps will one day be absorbed into Emacs core and all this silliness will be unnecessary but until then you will have to update your init.el to keep using them.

Andrea Corallo just announced that Emacs.30.0.92, the second pretest for Emacs 30.1, is now available from https://alpha.gnu.org/gnu/emacs/pretest/emacs-30.0.92.tar.xz. The associated signature file is at https://alpha.gnu.org/gnu/emacs/pretest/emacs-30.0.92.tar.xz.sig. If you can, the developers would like you to try it out and report any problems. You can view a summary of the changes by reading https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-30, an online version of the NEWS file.

It’s really important that the pretest get as much testing as possible so that we can move on to the release candidate(s) and finally Emacs 30.1 itself. Help out if you can.

Álvaro Ramírez has another tweak to his Dired display environment. This time it’s a patch to hide the absolute path of the current directory in Dired listings. Ramírez likes to display minimal information in his Dired listings because, as he says, the full listing is only a toggle away so why clutter up your display with a bunch of information.

I’ve never understood this. I always want to see as much information as possible and I don’t want to do anything extra to see it. The last time I ranted about this, commenters jumped in to say it was all about not having enough screen real estate but even with my flagging eyesight, I’ve always been able to fit the whole Dired file listing in a split window of my 13″ laptop. Even if that’s not the case, removing the line at the top of the listing with the absolute path does nothing to decrease the width of the display.

Still, lots of folks have other values and really do want to see only the information they absolutely need. As usual, Emacs lets us have it our way. You can display all the available information or you can opt for abreviated information and simply toggle the display if you need more.

If you’re in the abbreviated information camp, take a look at Ramírez’s post to see how to prune the display. If you’re in my “show me everything” camp, the good news is that you don’t have to do anything: Emacs will show it all to you¹.

(setq diredp-hide-details-initially-flag nil)

As many of you know, I’m fascinated by nontraditional users of Emacs. By “nontraditional users” I mean people outside of engineering and the sciences. I like to hear how novelists and people in the humanities leverage the power of Emacs in their work.

Almost all those nontraditional users learned to write their papers with—and are mostly still expected to use—the death traps that are Microsoft Word and Google Docs. It takes, therefore, an extraordinary commitment on their part to move to Emacs. Almost all who do, never look back.

Over at the Emacs subreddit, DevMahasen, who describes himself as a novelist and filmmaker, was already halfway there because he was a devoted NeoVim user. Still, he wanted to try Emacs but he couldn’t get his mind around it. Then he found the Emacs-kick repository, an kickstarter for Vim/NeoVim users. Once he tried that, everything clicked. Now he’s on his way to being another nontraditional Emacs user.

The Emacs-kick configuration is meant for Vim/NeoVim users and makes the transition as easy as possible. As you all know, I went through a similar transformation but I just took the plunge and started using vanilla Emacs. Honestly, it wasn’t that much of a problem but, of course, I’m not a nontraditional user and editors of various sorts seem natural to me so my experience may not be relevant to those who are.

Whatever type of user you are, if you’re considering transitioning from Vim/NeoVim to Emacs, you should give the Emacs-kick repository a look.