Irreal

Almost every Emacs user knows that you can use Esc as the Meta key. It started because keyboards between, say, the Space Cadet keyboard and modern keyboards didn’t have an Alt key to act as Meta.

The practice lives on. Guys like Mike Zamansky started with keyboards lacking an Alt key and continue using Esc out of muscle memory. I somehow missed all that and I’ve always considered it a bit odd but dismissed it as ingrained muscle memory as in Zamansky’s case.

Bozhidar Batsov has a different take. He started using the Alt key for Meta but has found that he likes using Esc more.

Batsov makes a cogent argument for preferring Esc and I found myself almost convinced but I know that at this stage it would be really difficult to retrain my muscle memory. It’s not just Alt → Esc. Rather it’s all those Meta + ... bindings that I think of a unit. I don’t think of them as Alt and then some other key(s) but as a single binding so switching to use Esc would mean relearning many, many bindings.

On the other hand, you don’t really have to choose. It’s not a configuration item: both Alt and Esc work out of the box so you can use either or both. Of course, that adds even more complexity.

In short, I find Batsov’s arguments compelling but not enough to go through the pain of retraining years of muscle memory. But I do have a new appreciation for those who use Esc.

A month ago, I wrote about Bozhidar Batsov’s post on debugging in Emacs. The idea was simple: if Emacs got an error, you could turn on debug-on-error and rerun the offending command. When the error occurs, Emacs will produce a backtrace to help you debug the problem. This can be helpful even for non-programmers.

Batsov is back with a followup post. In his latest post, he makes clear that Emacs is not just displaying a backtrace. What’s really happening is that you’ve been dumped into the bugger and you can query it for information on what happened.

Batsov provides a list of some of the things the debugger can provide and the (single letter) commands to invoke them. You can, for example, examine the current values of variables, evaluate expressions, step through code, continue execution, view help, or simply quit the debugger.

Programmers are, of course, comfortable with all of this but even less technical people can use it profitably. Take a look at Batsov’s post to help you get ready for the next time you have an unexplained Emacs error.

If you’re like me and hate CamelCaseMode and all its evil brethren, there’s a solution: glasses-mode. Ruslan Bekenev reminds us of a long standing command that will display camel case names as underscore delimited instead. By “display” I mean that the underlying code isn’t changed, just the way it’s displayed to you. Many of us find it hard to read camel cased identifiers so this is a useful functionality.

It would be worth knowing about even if it just displayed the identifiers sanely but there’s more. You can edit the text and the identifiers will be automatically adjusted. You can even grep for the identifier under cursor and the right thing will happen because, after all, the buffer isn’t changed, just what you see.

This is, to be sure, a small thing but it’s another example of how all those small things add up to make editing with Emacs easy and a joy. If you don’t already know about glasses-mode, take a look at Bekenev’s post.

It’s a common complaint that Emacs is hard to configure. After all, you have to learn Elisp and all sorts of other arcana just so you can edit a file. It’s all nonsense, of course. Lots of non-programmers and even profoundly non-technical people use Emacs daily in their work. Some are authors, others come for Org, and some just want an easy way to edit text files.

A fine example is Nuno Salgueiro, who, while not non-technical, is definitely not a programmer but is nevertheless a knowledgeable and effective Emacs user. You can read about his use of Emacs here.

Anyway, my nominee for curmudgeon-of-the-day is precompute who argues that Emacs is not really that hard to configure. It’s nice to have company in the curmudgeon corner.

Precompute argues that you don’t need to know much Elisp to effectively configure Emacs and that it’s better to start with vanilla Emacs and configure it to your liking than it is to use something like Doom.

Many people that I respect are Doom and Spacemacs users and swear by them but I’ve never seen the attraction. I started with vanilla Emacs and built my configuration as I went along. It worked well for me.

As usual, there’s a lot of meat in the comments. Some say that Elisp is a barrier and others dismiss the idea and say that Emacs really is easy to configure.

When I was beginning and didn’t know a lot of Elisp—although I was comfortable with Lisp—I simply searched for the problem I was trying to solve and pasted the solution into my init.el even if I didn’t completely understand it. Now, of course, there’s nothing in my configuration that I don’t completely understand. That’s the point: you start out as a beginner understanding little and evolve to an experienced user with a good command of Emacs and its configuration.

James Cherti has a quick tip worth reviewing if you’re not familiar with highlighting keywords in your source code. The idea is simple; you merely add the regexes for the keywords that you want to highlight to a font-lock-add-keywords call.

The normal way of doing that is to add the font-lock-add-keywords call to a function and invoke the function from a hook function for wherever you want it to take effect. In Cherti’s case he wants it to take effect in all his programming buffers so he adds it to the prog-mode-hook.

When I read Cherti’s post it seemed vaguely familiar so I checked my init.el and discovered that long ago before I really knew what I was doing, I added some silly Elisp macro I wrote to the list of keywords to be added to Elisp buffers. I did it just as Cherti suggests but added it to the emacs-lisp-mode-hook and lisp-onteraction-mode-hook instead of prog-mode-hook.

In any event, it you want to emphasize certain tags in your code, it’s easy to do. You can specify where they should be emphasized by adding the call to specific hook functions. The font-lock-add-keywords function also allows you to adjust the font face for the keywords if you’d like. See Cherti’s post or the documentation for details.

I’m happy to say that the Irreal bunker is now running Emacs 30.1. I was going to just note this as a footnote to a regular post but there were a couple of problems that I thought were worth mentioning.

The first is the usual problem with macOS. When you compile a new Emacs (or anything else for that matter), macOS won’t run it until you assure the OS that it’s okay. The way to do that seems to change with every release but the current method is the go to System Settings → Privacy & Security, scroll down to the bottom and okay the loading of the currently embargoed app. As I said, this seems to change all the time so it’s best to ask the Duck or whatever your favorite search engine is. I’m mentioning this because fragbot2 complained in this post that macOS wouldn’t load his new Emacs.

The other problem was that many ordinary commands (like Meta+x ...) didn’t work because of some problem with marginalia. I disabled marginalia and things started working again. Once I had a stable Emacs, I deleted marginalia from the Elpa directory, re-enabled marginalia, and restarted Emacs. That cleared up all the problems and now Emacs is working fine. I’m writing this post with it and haven’t had any problems at all.

Fragbot2 also noted that he had problems even when he installed emacs-plus from Brew. He may have similar problems with an outdated Elpa package. If you’re experiencing similar problems, check your *Messages* buffer for problems with packages. There are easier ways of dealing with those problems but I just delete the offending package from my Elpa directory and restart Emacs. That works because I use use-package with the ensure tag to ensure that my packages are always loaded.

Rejoice Emacsers. Stefan Kangas writes that as promised earlier this week, Emacs 30.1 has been released. You can check out the NEWS file if you want to know what’s new in this release.

I’m writing this on Sunday evening and have not yet had time to compile and install the new version but I have every confidence that this will be a stable release. I’ll install it in the next day or two and let you know if there are any problems.

In the meantime, thanks to everyone who worked so hard to get this release out. You guys really are heroes.

James Dyer is continuing his quest to remove as many third party packages as possible from his configuration. This time he’s replacing Magit with vc-mode.

As I’ve said before, I don’t understand this urge to replace more or less proven and debugged code with a homegrown version. Sure, you understand exactly what’s going on and you can make it do precisely what you want but you’re undoubtedly going to introduce bugs that the package has probably already resolved. It’s not as if you’re reducing the Emacs footprint by any significant amount so why bother?

In this case, though, Dyer has a point. Dyer uses Git at home but Subversion at work. Magit, of course, is for Git so rather than negotiate two different interfaces, he’s settled on one. That makes perfect sense to me. Emacs is, after all, all about making editing easier.

Happily, I use Git exclusively so I don’t have to deal with this issue but if I did, I’d probably do just what Dyer is doing. It makes sense to avoid context switches whenever you can and using more than one interface for version control is definitely a context switch.

I still don’t understand the urge to purge packages—except in special circumstances—but sometimes, as in Dyer’s case, it makes sense. To be clear, as I’ve said before, I don’t begrudge Dyer or anyone else the ability to configure Emacs the way they like. I’m only saying I don’t always understand the urge and it’s better to understand things than not. Or so I’ve been told.