Irreal

After a considerable amount of back and forth on the Emacs Devel Mailing List, Charles Choi’s Casual Suite has been accepted for inclusion on the NonGnu ELPA repository. If you’re already a Casual user, this makes no substantive difference. You can still get the suite from MELPA as you always have but it will also be available on the NonGnu repository.

Evidently Choi decided to seek NonGnu placement because some folks object to MELPA on philosophical grounds. I’m not sure I understand what the issue is other than MELPA is not officially canonized by the FSF.

To me, that’s just like insisting on a small init.el on religiously grounds. It merely means that you can’t take advantage of all Emacs has to offer. Whatever the FSF’s feeling on the issue, MELPA is, in fact, the premier ELPA repository and almost every package worth having is represented there, and many of them only there.

Still, choices are good and now we have more of them. If, for whatever reason, you have an objection to MELPA, you can still take advantage of the Casual Suite.

Bozhidar Batsov has been blogging up a storm on recent additions to Emacs that make our editing sessions easier. His latest post is about a successor to expand-region, expreg. Batsov has been a heavy user of expand-region for many years. The problem with it is that it requires hand written functions for each language that it supports.

As a result of his recent work integrating Tree-sitter into many of his packages, he thought it would make sense to reimplement expand-region as a Tree-sitter based package so that bespoke functions wouldn’t have to be written for each language. It turns out that Yuan Fu, who implemented the Emacs builtin Tree-sitter, had already done it.

Batsov loves expreg and doesn’t see why anyone who isn’t depending on some artifact of expand-region wouldn’t adopt it. Take a look at his post for more details.

In the comments over at the Emacs subreddit Karthink says that he has a constellation of packages that depend on expand-region and that it would be very hard for him to change. Spartanork says that he had a hard time getting Tree-sitter installed. Those two comments suggest that expreg may not be for everyone.

I’ve had expand-region installed for a long time but I don’t use it as much as I should. At this point in my life, virtually all my coding is done in either Elisp or C, for which expand-region works well. It also does the right thing in a prose buffer so I see no reason to change but if you’re using a lot of languages, you should definitely check out expreg.

As I wrote yesterday, a lot of really interesting posts popped up all of a sudden and I speculated that I might have to break my rule about not covering items that Sacha has already mentioned. I’m giving myself leave to mention at least one more post from last week.

Bozhidar Batsov has a nice post that explores Emacs line wrapping. As he says, there are basically two ways of doing that:

1. Hard wrapping that inserts an actual newline in the text to wrap the line at the logical screen width
2. Soft wrapping with visual-line-mode that doesn’t change the actual text but changes the representation on screen

The problem with visual-line-mode is that it doesn’t respect the indentation context and merely wraps the line at the logical screen edge, which can make the screen representation of the text seem strange. Happily, all this is fixed in Emacs 30 with visual-wrap-prefix-mode that automatically computes the indentation context and indents the text appropriately.

I never noticed this problem before, probably because I turn on visual-line-mode only for prose buffers, never for code buffers. If you are going to export those prose buffers, you really want visual-line-mode so that the text will display correctly on any screen.

Still, I was interested in visual-wrap-prefix-mode because I had never seen the bad wrapping described by Batsov. My writing is mostly straight prose without a lot of fancy indenting such as you might get with, say, poetry. The only time it comes up is with lists like the one above. When I turned visual-wrap-prefix-mode for this buffer, it did indent the subsequent lines of each item but I never really noticed the bad indentation before because it gets rendered correctly when I export it.

In any event, you should definitely take a look at Batsov’s post if you’re having word wrap problems.

When it rains, it pours. Sometimes I find it hard to find an interesting topic to write about. Other times, like today, four or five topics pop up. The problem is that today is Sunday and tomorrow Sacha will be publishing her weekly Emacs News. I generally try not to write about things that she’s already covered but I may have to break that rule for some of these interesting topics.

For me, the most exciting thing I’ve found today is Bozhidar Batsov’s post on Preview Regex Replacements as Diffs. It addresses a problem we’ve all had. You want to do a query-replace-regexp on a large file—or even multiple files—but you’re a bit nervous that maybe your regex isn’t quite right and the command might make a change you don’t want. So you step through each change, which is time consuming and a pain.

As Batsov explains, that got a lot easier in Emacs 30. There’s a new command, replace-regexp-as-diff that runs the regexp replace process but instead of actually making the changes, it produces a diff file in a separate buffer. That way you can see all the changes that would be made. If you’re happy with them, you can simply apply the diff buffer as a patch with diff-ediff-patch to apply them. If you’re not happy, you can simply delete the diff buffer.

There are two related commands: multi-file-replace-regexp-as-diff and dired-do-replace-regexp-as-diff for handling multiple files. The Dired variety is probably the easiest to use because you can simply mark the files you want to change in a Dired buffer and call dired-do-replace-regexp-as-diff to generate a diff for them all.

Batsov speculates that in the age of AI, people won’t be as interested in this type of command. I disagree strongly. It’s useful not only for coding but for writing pose or any other text-based file that you might want to edit.

If you’re an Emacs user, I urge you to take a look at Batsov’s post. It’s about a really useful new(ish) feature of Emacs that you can probably make good use of.

Over at the Emacs subreddit, alraban tells a nice story about game development with Emacs. The TL;DR is that it’s amazingly good. Alraban isn’t a professional developer but has been a hobbyist since the 80s. He has, several times, tried to write a game but never made anything he felt was performant enough to ship.

Recently he decided to try again. He used the Godot engine because he wanted to work with FOSS tools but he didn’t like the builtin editor or GUI so as a long time Emacs user, he thought he’d give Emacs a try.

Airaban was amazed at how good the experience was. The amazement wasn’t that you could develop games in Emacs—of course you can; people are doing it everyday—but at how good the tooling was and at how smooth and delightful the process was. Even as a long term user who “pretty much live[d] in Emacs” he was surprised at how much tooling there was available and how good it was. As he puts it,

It was like starting a home improvement project I’d never done before, and discovering that I already had all the tools I needed in the basement.

Most of us are pretty familiar with the Emacs tooling associated with our normal tasks. The takeaway from airaban’s post is that you’re apt to be surprised at what’s available when you move to a new task.

This is a short post and only takes a couple of minutes to read. It’s well worth your time.

Yi-Ping Pan has an interesting post that recapitulates one of my favorite hobby horses: Emacs is actually a modern day Lisp Machine that happens to ship with an embedded editor. Pan kept trying other editors but always returned to Emacs. Finally, he stopped treating it as merely a tool and started reading the C source code. What he discovered is what I’ve been preaching for years: Emacs is actually a C-based Lisp interpreter with an embedded text editor.

Pan’s post—the first in a series about Emacs internals—recounts how Emacs grew from a set of TECO macros to a stand alone application built on its own Lisp interpreter. Other editors have tried to recreate this magic but they have all failed because of Greenspun’s Tenth Rule:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Emacs, on the other hand, started with an actual Lisp interpreter and layered a text editor on top of that interpreter. That enables the magic. It’s possible to modify any particular editor function simply by rewriting it in Elisp and adding it to your configuration. Similarly, you can write your own editing—or even general purpose—functions and add them to the Emacs runtime simply by adding them to your configuration.

Pan announced his post over at the Emacs subreddit and, as usual, the comments are instructive. To me, the most interesting comments lamented that Lisp was never able “to fix” the parenthesis problem. I have to admit that it makes me grumpy every time I see someone complaining about parentheses in Lisp. To me, it’s one of Lisp’s successes, not one of its failures. That’s why the planned m-expressions using a more conventional syntax never caught on. Lispers like and prefer s-expressions.

In any event, Pan’s post is worth a couple of minutes of your time. Head over and take a look.