Irreal

For all you Emacs nerds out there here’s a bit of porn. It’s almost like those joke pictures you see of Emacs setups but this one appears to be real.

As much as I like the idea of this environment, I’m not sure that I’d want to use it. As some of the commenters noted, it’s going to make your neck sore but for me the question is why you need to see all that information? Sure, it’s useful to be able to see two or even three files at the same time when you’re working but I’m not sure why you need to see eight or nine at once. It seems like lurking distraction to me.

I get that you might want to have, say, an email buffer and maybe even a text message buffer open but I’m at a loss of what to do with nine visible buffers. Of course, it’s different strokes for different folks so whatever works for you is okay with me.

And I gotta admit it looks really cool and is sure to give you nerd creds from just about everybody.

Emacs elements has another interesting video, this time on some commands that he’s rebound for quick invocation. Those commands are (roughly):

• kill-buffer
• set-mark-command (Push mark)
• set-mark-command (Pop mark)
• exchange-point-and-mark
• jump-out-of-pair (A custom command)

He begins the video with some praise for the IBM Model M keyboard that he uses. I can relate. As I’ve written before, it’s the greatest keyboard every made. It’s layout is pretty standard so whatever “standard” keyboard you’re using probably has a very similar layout.

Emacs customization, of course, is all about making it as frictionless as possible for your workflow so it makes no sense to criticize someone else’s bindings but it’s interesting how different his choices are from mine.

He uses Ctrl+1, Meta+1, and Meta+2 for some of those commands. He says re realizes that theese are prefix keys but says he never uses them. I, on the other hand, use them all the time. If I want to delete 2 words, I do it with Meta+2 Meta+d. Similarly, if I want to delete 3 characters, it’s Ctrl+3 Ctrl+d. These are all burned into my muscle memory and I’d never give them up.

There’s more to his customization than just rebinding the keys. Most of the above commands also activate the mark and result in highlighting regions. That’s almost never what I want and neither does he. He has a bit of custom code to deactivate the mark so that doesn’t happen. Even if, like me, you don’t care for his rebindings, you may want to grab his code to eliminate the mark activation.

This is a short video and worth a few minutes of your time.

All of us Emacs nerds are familiar with Neal Stephenon’s essay In the Beginning…Was the Command Line, in which he describes Emacs as the thermonuclear word processor. A couple of years ago, he did a podcast with Lex Fridman in which he expands on his remarks and comments on the longevity of Emacs.

Fridman asked him if he thought that Emacs would still be around in, say, a hundred years. Stephenon’s answer invoked the John Henry legend where in the end, Henry was unable to keep up with the steam hammer. Stephenson says that Microsoft and Apple are pouring so much money and effort into VS Code and XCode that eventually Emacs won’t be able to keep up.

I don’t think that XCode is an issue in this discussion. It’s not primarily a text editor and is, in any even, very specific to the Apple universe. VS Code, on the other hand, can certainly be said to be an Emacs competitor. I don’t think it’s as powerful or full featured as Emacs but it does have a lot of money and power behind it. Whether Microsoft itself will survive for a hundred years and if they do whether they’ll find it economically advantageous to continue supporting VS Code are open questions.

I think that technology 100 years from now will look so different from what we have today that virtually no technology we have now will be extant. That will probably include Emacs. On the other hand, Emacs has been defying the odds for a long time and may surprise us all. What do you think?

Arialdo Martini is back with a very informative post about using registers to store buffer locations and other data. He starts with positing the need to store buffer locations by name rather than storing them in a ring buffer as he discussed in his post on the mark ring and then gives two possible implementations.

Of course, that’s not necessary because Emacs already has functions to do this. I generally use registers to store other information such as window configurations and text I need to insert repeatedly into a document but storing buffer locations can be useful.

It turns out that the Emacs implementation is much more robust than you might imagine. For example, if you close a buffer that is stored in a register and is displaying a file, Emacs will update the register to a file-query that will reload the buffer if you jump to the register containing the reference.

But it gets better. Martini shows how you can make registers persist across Emacs sessions. All of this is builtin to Emacs and available simply by invoking the requisite functions.

The only thing that Martini doesn’t mention is that the register keys aren’t stored as a single character but as a symbol reference.That means that you can name a register as a symbol (in Elisp), which makes it easy to store, say, window configurations without risking having it overwritten interactively. I use this all the time to run certain functions in full screen and then restore the previous window configuration when I’m done.

The thing about registers, as Martini says, is that they’re implemented using normal Elisp data structures that are available to end users to use in any way they see fit. It’s another example of how configurable Emacs is.