Irreal

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.

Note: As I was preparing tomorrow’s post, I noticed that I forgot to publish today’s. Sorry. Here it is, better late than never.

Over at Meta Redux, Bozhidar Batsov has announced the release of Flycheck 36. It has, he says, been a long time coming but he’s really happy with it.

He’s added a couple of new language checkers—javascript-oxlint and org-lint—fixed a security issue, and added some features to ShellCheck. There are also quality of life improvements and bug fixes. Additionally, he’s updated the app’s Web site.

Take a look at Batsov’s post for all the details. Batsov notes that many people have assumed that Flycheck is essentially dead because of the builtin Flymake’s integration with Eglot but he says that Flycheck is alive and well and continuing to evolve.

If you’re a Flycheck user or interested in it, all this is good news. Batsov has put a lot of work into improving it and has plans for more. He explicitly asks those who want additional features to let him know or better yet to submit a PR. In any event, you should take a look at Batsov’s post to see all the new features and improvements.

The fates are still punishing me for leaving home for travel. Today I had two errands to run:

1. Renew a driver license
2. Return an unused TV set top box to my provider

The DMV is, of course, a red flag but it turned out taking 3 hours. Three hours at the DMV is no one’s idea of a good time. After I staggered out of the DMV I went to my provider to drop off the TV set top box. That should take about 5 minutes, right? Silly you and me. That took an hour and a half.

In any event, I’m exhausted and ready for bed so today’s post is going to be ultrashort. The other day I wrote about Prot’s post on using --init-directory as an aid in debugging. Serendipitously, I ran across this post about ready-player freezing. The developer, Álvaro Ramírez, asks the user to provide information on his configuration and Emacs version.

This is a perfect example of where Prot’s advice would be useful. The user could easily build and install a temporary init.el to eliminate everything but what’s needed to produce the problem. Doing so might even allow the user to discover the problem on their own.

The standard advice people get when they complain about some bug or difficulty with Emacs is to restart it with -q or -Q to see if the problem persists. The problem with that advice is that the difficulty may be with a package. In that case you want to load at least the offending package and its configuration. That used to involve moving or renaming your init.el so that you could install the minimal init.el that produced the problem. As of Emacs 29 that got easier with the introduction of the --init-directory parameter that tells Emacs to load it’s configuration from a different directory.

Protesilaos Stavrou (Prot) has a nice post that explains how to use this feature when you experience a problem and want to file a bug report. The main problem, of course, is what to put in your new init.el. Prot recommends using use-package with :ensure t (and whatever configuration you’re using) to load the package.

Sometimes you might have to build the package from source rather than simply loading it from one of the ELPA repositories. Prot discusses how to do this using package-vc-install to grab the source directly from its git repository. He has some sample code showing how to do this.

Finally, he has some general recommendations that you can use to make the developer’s life a bit easier. On the other hand, if you are the package developer, the --init-directory trick can save a lot of time in locating bugs. In either case, take a look at Prot’s post. There’s a lot of good information in it.

Last week I wrote about Álvaro Ramírez’s new Winpulse package. The purpose of the package is to flash the window receiving focus when you use the other-window command. I wrote that I chose a different solution—changing the color of the mode line—that I felt was better because it provided a lasting indication of the active window.

In his latest Bending Emacs video, Ramírez expounds a bit more on why he chose the solution he did. The main reason appears to be that he sometimes turns off the mode line in some of his windows so my solution obviously wouldn’t work in that situation. Take a look at his video to see his complete argument.

In my previous post on Winpulse, I noted that you could, of course, use both his and my solution. I don’t think that would be worthwhile for me but in his video, Ramírez mentions Pulsar, a package similar to Winpulse that flashes the current line of the buffer getting focus instead of the entire window.

That seems to me a be something I might want to do since it helps locate the point in the new window. As always, Emacs lets you have things exactly the way you want them.

Ramírez and I tend to like the same sorts of things so our disagreement on this issue initially puzzled me. The answer, I think, is that when he switches windows, he just cycles through all the windows in the frame. I, on the other hand, use ace-window that lets me choose the window I want to change to directly. Again, this is a matter of choice but it helps explain why he and I chose different solutions.

The Bending Emacs 11 video is 8 minutes and 45 seconds so it such be easy to find time for it. If you’d like an enhanced way of seeing what window you’re switching to, take a look