Irreal

RMS presented a talk at the EmacsConf 2022 meeting on what he’d like to see and not see in Emacs. His first point was to dismiss the idea of replacing Elisp with something like JavaScript. Besides the technical infeasibility due to the vast repository of packages written in Elisp, RMS notes that these languages are not as powerful and useful as the Lisp dialects and that it would be foolish to switch even if we could.

RMS takes this opportunity to deliver a mini-jihad about JavaScript. Everyone loves to hate JavaScript, of course, but it’s hard to see how it can be blamed for its misuse in browsers. Had the JavaScript niche been filled by Scheme—as almost happened—would Stallman still blame Scheme itself for its misuse?

He discusses many possible ways to change Emacs but to me the most controversial is his desire to support a WYSIWYG word processor in Emacs. I have never understood why anyone would want to do this and I am definitely against it.

Such editors never live up to their promises and almost always fail to deliver decent final documents. Further, they reduce the user’s control over the final output, something that RMS criticizes modern Web browsers for earlier in his talk. There is no real need for such a thing. Org mode provides any easy way to produce excellent looking documents—typeset with Latex—with a very lightweight markup language. It’s easy—certainly easier than with something like Word or its evil siblings—for a casual user to use it to produce letters and simple documents but it can also be used to produce complex and sophisticated documents.

Worse yet, what would a file produced by such an extension look like? It certainly wouldn’t be plain text; it would be a proprietary—albeit open source—format. Who needs or wants that? And, of course, it would set up a feature race with Word and similar ilk that would lead to further bloat and incomprehensibility.

And who, exactly, is the constituency for this feature besides Stallman? I’m pretty sure that there’s not a single user out there who is thinking, “I’d use Emacs if only it had a WYSIWYG word processor” and I’d be surprised if there is any significant number of Emacs users who want such a thing.

In any event, it’s interesting to get Stallman’s (up to date) views on these issues. The talk is 17 minutes long so plan accordingly.

Jon Eskin has a revealing post that shows how easy it is to use the Elisp debugger. The debugger, Edebug, is documented in the Emacs Lisp manual so of course it’s always available in your Emacs session.

What I liked about the post was that it shows how easy it is to use Edebug to solve a problem even if you don’t really know the code base. Usually when you think about a debugger, there’s a supposition that it will be complex, hard to use, and have lots of mysterious commands. Eskin’s post shows otherwise.

The entire debugging session involved two commands. First, the suspect function is intrumented with Ctrl+u Meta+Ctrl+x so that Eskin could step through the function and see what it was doing. It turned out that a variable was being unexpectedly changed. To track down the culprit, Eskin put a watchpoint on the variable and was able to see exactly what was changing it. After that, the problem and its fix was obvious.

There’s more to Edebug, of course, but it’s amazing how far you can get with just the two commands that Eskin used. Notice that Eskin wasn’t writing Elisp code, he merely wanted to track down a problem in existing code. That shows that Edebug can be useful to many different types of users. If you aren’t already familiar with Edebug, take a look at Eskin’s post and then read over the Edebug chapter in the Elisp manual.

Stefan Kangas just announced that use-package has been merged into the emacs-29 branch. I’m inclined to take a conservative view towards moving packages into core Emacs, believing that a package should prove its worth and stability over an extended time before being considered for core.

The use-package macro has clearly met that standard. It really does make configuring packages simpler and the size of the configuration files smaller. Like many of our most useful tools, use-package was intended to make things a bit easier for its author, John Wiegley. He put it on GitHub and soon many people were using it and offering extensions. The :ensure keyword, for example, was implemented by one those users. Wiegley himself doesn’t use it because his workflow is a bit different.

The use-package package is a small thing but it does make my life simpler and I’m glad to see it get merged into core. Thanks to Wiegley, Kangas, and the others who made this happen.

As most Irreal readers know, Protesilaos Stavrou (Prot) is looking for a new job. Part of his preparations is learning Clojure so of course he’s produced a video on using Clojure in Emacs with Clojure. It’s an elementary exposition but definitely worth watching.

The main point of the video is not Clojure itself but rather the use of Cider and the evaluation of expressions in the context of the code buffer. He shows how you can evaluate an expression from within the code buffer and how you can easily switch to the Clojure REPL to try things out.

It’s another example of exploratory programming that I’ve written about before. If you haven’t experienced it, it’s hard to overstate the value of having the REPL always available to test out functions or even expressions. It makes programming much more efficient and fun.

The video is just short of 27 minutes so you’ll have to schedule some time. Prot has promised more videos on Clojure, which I’m looking forward to. In the mean time, if you want to get a sense of what using Cider is like, take a look at his video. If you want another example, check out Mike Zamansky’s video on Day 1 and 2 of the 2022 Advent of Code challenge. He uses Clojure and demonstrates its use on nontrivial problems.