Irreal

Two or three weeks ago in the comments to my post How Many Years Have You Been Using Emacs? I opined that the biggest thing missing from Emacs was a decent threading model. I also admitted that it was a very hard problem and one that I was glad I didn’t have to solve.

Dickmao is a braver soul and decided to try a proof of concept. After all, he said, how hard could it be? The problem with implementing threads in Emacs is that historically there was no lexical binding; all the non-local symbols were dynamically bound globals.

Dickmao’s idea was simple: give each thread its own obarray so that it would have its own copy of each symbol. It didn’t take any time at all for things to blow up. He immediately encountered a static buffer in the print routine. He played wack-a-mole for a while but there always seemed to be another problem.

He explains all this in his video. After you watch it, you will have a much better understanding of the problem with threads in Emacs. The video is only 4 minutes, 12 seconds so it should be easy to fit in.

Emacs 29 should be officially released soon. Many of you, I know, are already running it. For those that haven’t already taken the plunge, Emacs Elements has a series of three videos that cover the installation and some of the features of Emacs 29. The videos are from 3 months ago but somehow I missed them then.

The first video deals with compiling Emacs 29 from source. The steps are captured in a Bash script that works for Mint/Ubuntu and probably, with minimal adjustments, any other Linux distribution. It won’t work on Macs, of course, but the steps are pretty much the same and could be adapted without much work.

The build is pretty vanilla except for enabling SVG and native compilation with the aot (ahead of time) option. The aot options compiles the Elisp files to native code during the build process so that things are snappier when Emacs is run for the first time.

The second video is probably the most interesting for most of us. It takes a look at some of the new features in Emacs 29. I written about a number of posts and videos that talk about the Emacs 29 features [1, 2, 3, 4, 5] and it’s interesting how different the list of additions the commenters think are most important. Think of this video as one perspective on that question.

Finally, the last video discusses enhanced image features new to Emacs 29. I don’t deal with images much so I wasn’t too interested in this video but if you do work with images, it’s certainly worth a few minutes of your time.

The videos are all pretty short so you can probably fit one of them in whenever you have a few spare minutes.

Good news from Eli Zaretskii: The first release candidate for Emacs 29.1 is available. This is, of course, the final stage of the prerelease cycle. Zaretskii says that if there are no problems with the release candidate, Emacs 29.1 will be released next week. That’s good news indeed.

I’m sure this release is stable and safe for even the most conservative Emacsers so if you can, help Zaretskii and the other developers with the final testing. As always, much thanks to all the developers for the huge amount of work that went into preparing this release.

Charles Choi has another great Emacs post. It’s about Moving Text Elegantly in Emacs. The TL;DR is that Choi considers some elegant ways of moving various text objects forward and backwards. It’s really a generalization of the transpose-* functions. We all know about transpose-chars and transpose-words and some of us even remember that you can do the same with sentences. On my system, at least, transpose-sentences isn’t bound to any keys but I use it rarely enough that I don’t mind typing in the command. It’s easy to remember the name so I consider it part of my toolkit.

There’s also a transpose-sexps but it’s action is a bit more mysterious. When you’re in a Lisp buffer, it does just what you’d think it would but for other languages or text based buffers the situation is more complicated. In those cases the idea of an s-expression is replaced by the more general “balanced expression”. A balanced expression is something between matching delimiters like “”, [], <> and so on. Part of what makes things so complicated is that what those delimiters are depends on the buffer mode.

Choi’s idea is to use a combination of moving forward or backward over a text object and the transpose functions to create a series of functions to move those objects forward or backward over objects of the same type. He motivates this with the example

["a", "b", "c", "d"]

Suppose, he says, you want to move the "a" forward into the third position so that the list becomes

["b", "c", "a", "d"]

It’s easy to brute force that, of course, but if you have to do it repeatedly, it quickly becomes tedious. Choi creates a simple function using just forward-sexp and transpose-sexps that does this easily. He has several functions for moving various objects forward and backward.¹

He also observes that these are seldom used routines and not worth remembering let alone binding a key sequence to. His solution is to add them to the Edit menu. That’s perfect because all you have to do is remember that they exist and can otherwise forget about them until you need them.

It’s a good post so take a look when you have a few minutes.

Emacs Elements has a great video on one of my favorite navigation packages: Avy. The idea is a generalization of Steve Yegge’s recommendation to navigate with search. When I first read Yegge’s tip it was an Epiphany to me. Suddenly, moving around a buffer was quick and easy. Abo-abo’s Avy generalizes Yegge’s idea and makes it even faster and easier. It’s my goto way of navigating and I’ve already used it several times while writing this post.

The video is an excellent introduction to Avy and what it can do. As the video notes, there are several commands that are similar but differ in subtle ways to provide a wide range of functionality. My first choice when I need a navigation command is always avy-goto-word-1. It provides an easy way of jumping to a word by specifying its first character.

My second most used Avy command is avy-goto-char-timer. The video fails to capture its true utility. The point of the timer is that you can type any number of characters until there’s a delay of the timer’s value and Avy will identify all the strings beginning with those characters and jump to the start of the one you select. It’s almost like using incremental search as Yegge suggests but the command leaves the point at the beginning of the string, which is convenient.

The video demonstrates two commands that I wasn’t aware of: avy-copy-line and avy-move-line that do just what it says on the tin. When you invoke one of the commands, each line is added to the list of targets and the one you choose is copied or moved to the point.

Finally, there’s avy-goto-line that allows you to immediately jump to a line without knowing its absolute line number. I have it bound to Meta+g Meta+g so that it’s really easy to invoke.

If you’re interested, here’s my complete Avy configuration:

(use-package avy
  :ensure t
  :diminish avy-mode
  :bind (("H-a"     . avy-goto-word-1)
         ("H-s"     . avy-goto-char-timer)
         ("M-g M-g" . avy-goto-line)
         ("M-g g"   . avy-goto-line)
         ("H-A"     . avy-goto-char))
  :config (setq avy-all-windows nil))

The Hyper+A binding is for those rare occasions when I want to jump into the middle of a word. The problem with it is that it generates a large number of targets. I never use the Meta+g g binding and don’t know why it’s still there.

If you aren’t using Avy, you’re working too hard. Take a look at the video to see what it has to offer. The video is only 7 minutes, 29 seconds so it should be easy to fit in.

Here’s a tiny tip from Zachary Kanfer. Like me, he prefers to keep his Emacs windows the same size. That’s pretty easy to do: when you split or delete a window resulting in an unbalanced layout, you can merely call balance-windows with Ctrl+x +.

I tend to stay with two windows so this doesn’t come up often for me but Kanfer has a richer window environment and one day he realized that he was doing too much manual work keeping his windows balanced. He noticed that they became unbalanced when he deleted or split windows so he wrote 4 lines of Elisp that arranged for those functions to call balance-windows after they ran. Now he longer has to think about balancing his widows; it just happens.

Aditya Athalye had declared Emacs configuration bankruptcy and decided to start over emphasizing package management. He decided to build his own configuration as opposed to relying on a starter package: build vs. purchase as he put it. He started by using some of the ideas in Bozhidar Batsov’s prelude distribution but depends mostly on John Wiegley’s use-package package.

Athalye believes that one of the secrets to sustainable Emacs configuration is to let software write as much of the boilerplate as possible. That’s precisely what macros do, of course, so he relies heavily on the use-package macro to write most of his package installation code. Using use-package has several advantages.

Not only does it take care of that boilerplate saving time in writing it and time in debugging errors from getting it wrong, it also simplifies your init.el file. The nice thing about it is that can also handle installing a package if it’s not already present. Once the package is present, the use-package also provides the configuration, including any keybindings the user might desire.

Athalye includes a copy of his init.el so far. It’s a work in progress and he indicates some of the things still to be done but the package management facilities are all in place. He makes a good case for using use-package and you should check it out if you aren’t already using it yourself.

I long ago converted all my require commands, except that for use-package itself, to the macro and have never looked back. It makes my init.el file simpler and more coherent. Take a look at Athalye’s post for a bit more information.

Over at the Emacs reddit, Gink0 asks What dev feature is available in emacs but not in the current mainstream IDEs? It’s sort of like the usual question of “What makes Emacs so great?” or “Why do you recommend Emacs?” but with the added constraint that it has to be things that other editors don’t have.

For me, the salient feature is that Emacs provides the closest thing we have to a modern light-weight Lisp Machine. It’s not the “Lisp Machine” part that matters, of course, it’s what “Lisp Machine” is shorthand for: a complete, totally, configurable, and even reprogrammable operating environment. That means that can do just about anything you do on a computer in Emacs and do it with a unified interface.

Many of the responses to Gink0 hinted at this but emphasized the configurability that Emacs has far in excess of other editors. Other responses mentioned Org mode and its enabling of literate programming. Other editors may support literate programming to varying degrees but Org mode’s code blocks are special. Not only can you have traditional literate programming in the Knuth sense but you can also embed executable code in an Org file and have the results of running that code appear in the file. It’s tremendously powerful regardless of whether or not you like Knuth’s version of Literate Programming.

Those are the big things. Some of the commenters mentioned smaller things such as narrowing, rectangular editing (although lots of editors have that), the best Vim emulation, undo tree, Eshell, and the notion of modes.

What’s on your list?

Mike Zamansky has the third video in his Learning Elisp series up. As promised, this one is about writing functions. As Zamansky points out, Elisp functions are pretty much the same as function in other languages except for the lack of a return statement and, of course, the syntax.

There are a couple of interesting aspects to Elisp functions. The first is the Doc String. Lots of languages have something similar but in Emacs the Doc String is automatically imported into the Help system so a user’s own functions are documented just like the built-in functions.

The second aspect is the interactive declaration. Including it makes the function “interactive”, which means that you can call it from the keyboard with Meta+x or by assigning it a key binding. My goal for writing Elisp is to write an interactive function where I remember to add the interactive declaration before I try to run it from the command line.

The video covers just the very basics of writing functions. Zamansky is planning on getting into some of the deeper aspect in later videos. This video is 12 minutes, 36 seconds long so you’ll probably have to schedule some time.