Irreal

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.

Lars Ingebrigtsen has an interesting post that discusses writing WordPress blog posts in HTML. Why would you want to do that? Ingebrigtsen’s answer is that the alternatives are harder to use. In particular he says that markup languages are as hard, or harder, to use than raw HTML.

Even though he’s an Emacs user, he frames the discussion in terms of Markdown instead of the much more capable Org mode. Ingebrigtsen makes the point that writing a Markdown link is pretty much the same as writing an HTML link but Emacs/Org-mode makes all this easy.

First of all, you can simply ask Org to insert a link and it will query you for the link and associated text and then format and insert the Org actual link for you. I can’t remember the last time I actually hand-formulated an Org link. But it gets better. In most cases I want to link to a Web page and I have a function that extracts the link and queries me for the associated text. That’s much easier than doing the same thing with raw HTML.

A lot of his post discusses the problems of dealing with images in posts. He uses ewp to deal with this and other matters of dealing with HTML. The Org mode solution is org2blog which seamlessly handles images and the formatting of an Org buffer into to a WordPress blog entry.

I don’t begrudge anyone the ability to write in raw HTML but I don’t think it’s true that it’s easier than writing in Org. On the other hand, one nice thing about ewp is that it can take a screenshot of everything that’s linked to so that it’s easy to see it by just hovering over the link. That helps deal with linkrot.

In any event, it’s an interesting post and worth taking a look at if you feel that you’d like to write in raw HTML.

I have family visiting so this is another short post. Charles Choi has an interesting tip for Emacs emoji users on macOS. I rarely use emojis anywhere but in texts so I wasn’t aware of Emacs facilities for choosing emojis. It turns out that emoji-list will work on any Emacs installation but that there’s a better system on macOS. That’s ns-do-show-character-palette, which pops up the usual macOS emoji picker.

If you use it a lot, it makes sense to bind it to a key sequence shortcut. Choi prefers to do this sort of thing from the menu system but, sadly, ns-do-show-character-palette is not in the Edit menu by default. It is, however, easy to add it and Choi’s post shows us how to do that.

If you like to add emojis to your emails, say, you use something like Mu4e or one of the other Emacs Emacs clients, and you’re on macOS you will probably find Choi’s post useful.

Just a quick post about a short note from Marcin Borkowski (mbork) concerning searching for the thing at point. Despite using Emacs for over 18 years I didn’t know about isearch-forward-thing-at-point.

As mbork says, it does just what it says. You invoke it with Meta+s Meta+. and it searches forward for whatever the point is on. This is something I want to do all the time and I was vaguely aware that it was possible but didn’t know exactly how to do it, so I’m really glad to see mbork’s post.

Finding out about this now serves to emphasize that learning Emacs really is a lifelong journey.