Irreal

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.

Stefan Kangas writes that the Emacs 30.1 release candidate 1 is available for download. This is one of, possibly the last, steps before the release of Emacs 30.1. There’s also a Windows binary available.

Kangas says that if there are no problems, Emacs 30.1 will be released on Sunday. Even if problems are found, the release of Emacs 30.1 is imminent.

As I always say at this stage of the development process, thanks to all the developers who volunteer their time and effort on the Emacs project. They really are heroes who don’t get nearly enough credit for their work on our behalf.

As I also always say at this juncture, it once again puts the lie to the claim that Emacs is an old, moribund technology that has been superseded by blingtastic editors like VS Code. Our editor’s development is ongoing and robust despite what the naysayers claim.

If you have the time and inclination, please download and test this release candidate.