Irreal

Charlie Holland has an interesting contribution to May’s Emacs Carnival, which this month is on the topic “If I may recommend…” His notion is that Emacs is an effortless bloom. The “effortless” part is because Emacs—contra conventional wisdom—is easy to use and can, in fact, significantly simplify your work flow by providing a uniform interface to several different computer programming languages and their environments. If you’ve ever had to negotiate such a collection, you know that this is not a trivial thing.

The “bloom” part is more nuanced. The idea is that like a rose whose roots “fan in” water and nutrients and whose flower “fans out” its petals and beauty to encourage pollination, Emacs has its own fanning in and out. The center of this action is the text buffer. Data from various sources can be fanned into a buffer from which it can be fanned out to various functions for processing. The altered text buffer can then be fanned out to other targets.

Holland’s post is a bit lyrical so you need to read it to get the full impact of his fan in, fan out metaphor. He considers whether any other editor could achieve the same power as Emacs. He concludes that any editor could, in theory, achieve the same power but in order to do so it would have to replicate the idea of the buffer as the single important data structure on which everything else operates.

It’s an interesting post worth a few minutes of your time.

Thanos Apollo has an interesting post about an almost forgotten Emacs battle: the choice between Bazaar and Git as the new version control system for Emacs. Twenty years ago, Emacs was still using CVS, a venerable RCS that was well past its sell date.. It was clear to everyone that a new system was needed. The question was which one. The two contenders were Bazaar and Git.

On the technical merits the choice was clear. Git was faster and more reliable and most, if not all, of the developers wanted to move to it. But there were political considerations. Bazaar was a GNU project and Git was not. RMS felt strongly that the GNU project should support its own applications and insisted that Bazaar be used and given a chance to improve. It was maintained by Canonical but they eventually abandoned the effort. Even though the development was stalled and error reports were piling up unresolved for years, RMS insisted on staying the course.

The saga would probably still be going on were it not for Eric Raymond (ESR). He had been working for some time on a utility to import various RCS systems into Git while maintaining whatever metadata the old system offered. At one point he decided to convert Emacs to Git. It was a particularly difficult problem because there was more than one source RCS in play and because some of the records were old and incomplete.

Nonetheless, ESR managed the conversion and in 2014 announced that he had the conversion scripts ready and was set to go. In November 2014 he ran his scripts and suddenly Emacs was available as a Git repo. The developers started using it and the battle was over.

Charles Choi is back with more menus. Most of you know that I generally eschew the use of Emacs menus but they definitely have a place in seldom used commands whose name or key shortcut are hard to remember. In most cases, it’s possible to play around with fuzzy command completion and find what you’re looking for but it’s a lot easier to simply use a menu if it’s there.

That’s where Choi’s latest update to Anju comes in. He says that the introduction of context-menu-mode in Emacs 28 made it possible to provide cotentxt sensitive menus for Elisp development and he has added it to the latest version of Anju.

His post has a couple of screen shots of his menus in action. In the first, the point is on a function definition and the menu, among other things, offers the choice to instrument that function. In the second, the function has been instrumented and now the (context sensitive) menu offers things you can do—such as step into, set a breakpoint, and others—with the function. Naturally all of this is dependent on where the point is. That’s the point: the menu is context sensitive.

Choi says that the use of the context menus has markedly improved his Elisp development. If you do some but not a lot of Emacs development, it may be a win for you. On the other hand, Choi certainly does do a lot of Emacs development and still finds it a win. Perhaps—no matter your normal workflow—you will too.

Marcin Borkowski (mbork) has an interesting post on the describe-personal-keybindings command. The idea is that the command lists the keybindings that you have set in your configuration. It’s convenient, mbork says, for checking that new Emacs releases haven’t stolen one of your bindings. It’s also interesting to see what bindings you’ve added and what, if anything, they’ve replaced.

But there’s a catch. In order for a personal keybinding to show up, it must have been set with the bind-key macro. That’s a problem for those of us who are long term users. Those who use use-package exclusively have no problem since the :bind command uses bind-key automatically but bindings set with, say, define-key will not appear in the describe-personal-keybindings output.

That’s inspired mbork to refactor his init.el to use use-pacjkage and for stand-alone bindings, the bind-key macro.

The minions are insisting that I mention what they consider the best part of mbork’s post. That, of course, concerned dark mode. Mbork begins his post by mentioning a Web app that provides a Web based cheat sheet of Emacs commands. Mbork says it’s a cool command but not for him because

if I were to create something like that, it would run in Emacs and not in the browser, it would definitely mention transpose-.* commands, and it would never be dark-mode-only;-).

The minions haven’t been causing much trouble lately so I thought it only fair to indulge their desire to get mbork’s dislike of dark mode on the record.

Those of us who have been around long enough remember Sacha Chua’s Emacs Chat videos. The last one was a decade ago but now that Chua’s daughter is a bit older, she’s decided to resurrect them. The first new episode, Emacs Chat 21, is with Amin Bandali with whom she’s worked on EmacsConf for the last 7 years.

The format is always the same. Chua and her guest discuss the guest’s Emacs configuration and how they’ve solved various problems. There’s way too much material for a quick recapitulation—the video is an hour and 12 minutes long—but there’s a transcript at the link so you can go through it at your leisure if you find the video’s pace too rapid.

There were a couple of things that I found particularly interesting. The first is the upcoming user-lisp-directory. It allows you to specify a directory for your Lisp files and Emacs will automatically compile them and add them to the load-path for you. Bandali uses it as a replacement for the package system because he prefers to configure things manually.

The second interesting thing for me was his use of EXWM (Emacs X Window Manager), which goes a long way towards the dream of bringing everything into Emacs. I’ve long wanted to try it out but as its name suggests, it works with the X-Windows system only. The Irreal bunker has famously standardized on Macs so EXWM is unavailable to us. I’d still love to try it though.

There’s a lot of material in the chat so you’ll have to watch it—or at least skim the transcript—to get the whole picture. There are links to his configuration so you can steal anything that seems useful to you.

I’m really happy to see Chua resurrecting her Emacs Chats. I really enjoyed the previous ones and learned a lot from them and I’m sure that will be true of the new ones too.

As I mentioned a few days ago, the Emacs 31 release process was on the verge of starting. Now Sean Whitton writes to tell us that the Emacs 31 branch has been created and that the feature freeze has begun.

This means that the Emacs 31 release cycle has begun and that’s what on the Emacs 31 branch is pretty much—modulo bug fixes and last minute emergency additions—what the final release will be like.

The release cycle—if you believe in history—is apt to be long but even though that can be frustrating it means that the final product is going to be rock solid.

Although I keep repeating it, I can’t say it enough: thanks to all the developers who selflessly donate their time and efforts to making and keeping Emacs one of the best—if not the best—editors available.