Irreal

If you’re interested in editors or even just Emacs internals you probably know about gap buffers. They’re a way of holding the data being edited so that it can be updated and displayed quickly and easily. It’s not the only method and certainly not the most obvious. The first thing most of us think of is an array of lines but gap buffers has substantial advantages over that.

The short story about gap buffers is that empty space is opened at the point so that text can be added, deleted, or edited. When the point is moved to another region, the old gap is closed and reopened at the new location. Newer editors mostly use more modern data structures for this such as piece tables or ropes.

Troy Hinckley has been experimenting with replacing the Emacs C core with Rust. Recently, he started looking at the best way to represent a text buffer. Rust, he says, has some particularly good implementations of ropes but he wondered whether they really were better than gap buffers for this particular application. He decided to answer the question scientifically.

He wrote an instrumented version of gap buffers and some of the Rust rope implementations and
ran some benchmarks. The results were illuminating. Gap buffers performed much better than you might expect against ropes. His post takes a detailed look at the question so you should definitely head on over there if you have any interest at all in the matter. It’s a good post and an excellent example of letting the evidence decide an issue.

The first official edition of the ELPA and Emacs Zine has been published. This edition is more concerned with Emacs than ELPA but it’s promising to be a useful resource for Emacs users. The current episode considers the discussion of clojure-ts-mode, the passing of Thien-Thi Nguyen, adding the compat library to Emacs core, package-vc, adding peg.el to core, some contributions to Eglot and Tree Sitter, and a discussion of perl-mode.

There’s also a discussion of Tree-Sitter and a list of new packages. The zine is looking for contributors so if you’re interested in making your voice heard, this is your opportunity.

This zine is a welcome addition to our community. You can think of it as an adjunct to Sacha’s Emacs News but with an emphasis on ELPA. In any event, it’s worth taking a look at.

This is a sort of advertisement for EmacsConf 2023. Sacha Chua has published a list of talks and it looks like it’s going to be a really great conference. The list is really useful. It’s not just roster of the talks and who is giving them; each entry includes a summary of the talk and a bit about the speaker.

If you follow Chua, you know that she’s done a lot this year to automate the management of the process. You can check her site for the posts describing what she’s done. She’s also giving a talk about the new processes she’s developed.

I’ve read through the list and looked at the description of the talks that seemed interesting to me and, as I said, the conference looks as if it’s going to be a win. If you’re like me, not every talk will be interesting to you but there are plenty, in various categories that will be. Even my interests, which are probably a bit eclectic, are well represented and I’m pretty sure that will be true for almost all Irreal readers.

One of the things I’ve learned from following Chua’s work this year is how much work she and the other volunteers do. That—and simply the love of automating things—is undoubtedly why she took to time to computerize as much of the process as possible. If you’d like to chip in, they’re always looking for volunteers. If you can’t help out, be sure to drop by in December to watch the talks that interest you and join in the discussions afterward. The conference will be online again this year so it should be relatively easy to attend.

Emacs Elements has a really excellent video on features, requires, and autoloads. The putative subject is speeding up the Emacs load process and perhaps even Emacs itself. The idea is that if, like me and Emacs Elements, you have a lot of specialized functions in your init.el or .emacs, you can extract them out to separate files that you can byte compile and perhaps set to autoload.

The autoloading will speed up your Emacs load time, of course, but even when you must require the file, byte compiling it will make Emacs run faster. The video explains how to set all this up. It turns out to be simple to configure and maintain.

The first step is to run emacs-init-time to find out how long Emacs is taking to load. That may or may not be useful. For example, my configuration involves decrypting and loading my authinfo file so my load time includes waiting for me to react to the password prompt and the time it takes me to enter it. You can solve this by loading Emacs twice in a row but regardless, if you think Emacs should show a bit more alacrity during loading, this video shows you some easy ways of accomplishing that.

Any reasonably experienced Emacs user knows about require and autoload and perhaps even feature but the details of how, exactly, they work may be a little murky. This video clears that up and shows you how to leverage them to speed up your Emacs load and running time.

Charles Choi offers a small tip that many of you might find useful. Choi spends a lot of time in online conferences and chats. These often involve interlocutors in other time zones and, of course, it’s useful to know what time it is in those time zones. For those of you who, like Choi and I, live in Emacs, there is the world-clock command that list the times in various time zones. You can open it another a buffer beside of below your chat buffer and stay on top what time it is for everybody you’re talking with.

The problem is that it’s a bit limited. Here’s the default output:

Seattle   Friday 06 October 15:30 PDT
New York  Friday 06 October 18:30 EDT
London    Friday 06 October 23:30 BST
Paris     Saturday 07 October 00:30 CEST
Bangalore Saturday 07 October 04:00 IST
Tokyo     Saturday 07 October 07:30 JST

That’s great but what if you’re talking to someone in Denver or Beijing? You can’t expect the command to list every possible place where you might be talking to someone, of course, but if you regularly chat with someone in Beijing, it would be nice to have it listed. This is Emacs so of course you can do that. It turns out that there’s an alist of TIMEZONE/PLACE that you can edit to customize the output to your liking.

Again, this is a small thing but it’s a nice amenity and, in the way of Emacs, you can configure it to meet your specific needs.

Over at Bob on Medical Device Software, Robert Nadler has a nifty post on his new package elfeed-curate. The idea is to select various articles in the elfeed feed list—possibly annotating them—and export them in a publishable format. Nadler uses it to publish a periodic summary of articles that he found useful or interesting on his blog. The post shows an example of the output as well as providing a link to an actual entry in his blog.

The basic workflow is simple and fast:

1. Mark any Elfeed entries that you want to curate and add an annotation if necessary.
2. Select the marked entries and export them with the elfeed-curate x key.
3. Publish the exported content.
4. If desired, tag the exported entries for later use.
5. Remove the marks from the exported entries.

There’s a lot of information about configuring and using elfeed-curate at its GitHub repository so be sure to take a look at that if you’re interested in the package. The only dependencies for elfeed-curate are Org and Elfeed. It’s available on MELPA so it’s easy to install. If you’re looking for an easy way to curate entries from your feed, this package seems like just the thing.

UPDATE [2023-10-06 Fri 17:44]: Erik L. Arneson has started using elfeed-curate to compile a list of interesting links for his blog.

Ankit has an interesting post about setting up a custom Tramp method. His use case is a little complicated but the TL;DR is that his work involves writing software to control robots. For testing and development, they have an internal service that allows the instantiation of virtual robots that they can test their software on.

Once a virtual robot is created, they sometimes need to adjust the configuration or examine logs. This requires logging onto the server for the particular virtual robot in question—a complicated process. Ankit discovered that Tramp is actually quite flexible and allows the definition of different access methods. We’re mostly familiar with the SSH method that is the usual way of using Tramp but the SSH method is just one service in the list that Tramp uses to define its services.

Ankit’s idea was to define a new method that allowed him to “sign in” to any of the virtual robots and perform whatever actions were needed. That turned out to be reasonably simple. He also implemented a Tramp completion method to complete the name of the robot that he wanted to sign into. The whole thing took a surprisingly small amount of code.

This is another wonderful example of how Emacs can be persuaded to do whatever tasks your workflow requires. None of you are apt to need to replicate his workflow but his post is a great go-by for rolling your own Tramp service.

Emacs Elements has a video on how to move Emacs from Windows to Linux. That may seem a little nichey but Irreal feels duty bound to provide whatever assistance it can in helping people migrate off of Windows to a sensible system. Although the video is specifically about moving to Linux, the advice works equally well for macOS or any Unix system except, perhaps, for the package manager—brew, apt, etc—needed to install dependencies.

The basic advice is to move your entire .emacs.d directory to the new system and then tweak it to work in its new home. Mostly that involves, as you’d think, changing the Windows paths to Unix format and adjusting them to point to the right place. But there are a couple of less obvious aspects that need attention. One of those is your theme. The video recommends disabling the theme and reinstalling later. Similarly, pdf-tools can cause problems and the video recommends deleting it from Elpa and reinstalling once you get Emacs running.

All that sounds a little complicated but is really no more difficult than moving between some Linux distributions. I like to factor out system specific data to separate files and load the appropriate file based on the host system. That allows me to have a “universal” init.el that works on all my machines and even makes moving to a new OS relatively easy.

If you’re planning on moving off Windows, this is a worthwhile video to watch.

Over at the Emacs subreddit, rebcabin-r has a short post on Ergonomics and Emacs. By ergonomics he doesn’t mean the usual issues of RSI and overused pinkies. Rather, he’s talking about a comfortable environment for writing and coding.

His experience closely parallels mine. He says that he looks forward to using Emacs and can work in it all day without being exhausted. Other apps, even “good” apps like Mathematica and IntelliJ, wear him out. Just today, I was working on a computer without Emacs and it was excruciating. I felt like taking a nap afterwards.

When I’m using Emacs—and especially Org mode—work just flows and I know that I can export whatever I’m writing to whatever format I need. Similarly, if I’m coding I know I can compile and even run the code without ever leaving Emacs.

My experience is that mouse usage plays a large part in this. If I can avoid the mouse things go a lot smoother. Part of that is probably because I have a lot of the Emacs navigation bindings available everywhere in macOS. Another aspect to my optimized workflow is the use of Alfred to minimize mouse use. As I’ve learned more about Alfred and internalized its use, I’ve mostly avoided using the mouse except within Safari. Even there, I can use Alfred to bring up Websites so my main mouse use in scrolling and clicking on links.

Still, nothing is more comfortable and natural to me than Emacs. I’m with rebcabin-r: I’m never completely happy working on my computer unless I’m in Emacs.