Irreal

Even if, like me, you mostly run Emacs in GUI mode, it’s sometimes desirable to invoke a terminal instance. Mostly it doesn’t matter which mode you’re in but there are a few things—font colors, for example—that you may want to set depending on which mode you’re in.

That means you need a way of determining the mode you’re running in. As Bozhidar Batsov tells us, that’s not hard: simply test the variable display-graphic-p. The problem comes when you have both modes running in a single instance of Emacs. In that case, one of the color schemes, say, is going to be wrong.

Batsov has a solution. The answer is to make the mode test in a after-make-frame-functions hook function. That way you can make frame specific settings for the appropriate mode. Here’s the example Batsov gives for setting the font text:

(add-hook 'after-make-frame-functions
  (lambda ()
    ;; we want some font only in GUI Emacs
    (when (display-graphics-p)
      (set-frame-font "DejaVu Sans Mono 28")))

As you see in this example, the code runs in the proper frame environment and the resulting customization is set for this frame only. That allows fine grained configurations even when an Emacs instance has both types of frames. Problem solved.

In a followup to his recent post on Modern Emacs, Bozhidar Batsov has a short offering that talks a little about Commercial Emacs. It’s a fork of GNU Emacs but it’s not the first one. There have been several others, most famously XEmacs, which was a reaction to the slowness in getting changes accepted into GNU Emacs. This latest fork was, as far as I can tell, made for the same reason.

The list of things the Commercial Emacs developers say they’ve fixed includes several long standing problems such as (finally) doing something about the long lines problem and integrating tree-sitter to replace the slow and brittle regex-based font locking code. There are other changes, as well. You can see the whole list in either Batsov’s post or the README at the Commercial Emacs GitHub site.

I’m a little surprised by the fork because as far as I can tell, Emacs development is relatively speedy and there have been regular releases so the situation is different from what it was when XEmacs was forked off. On the other hand, there are a lot of FSF politics to negotiate when you want to make a change. Sometimes changes are rejected for political—as opposed to engineering—reasons.

Whatever the reasons, I’m sure that both distributions will benefit from new the blood and ideas.

Bozhidar Batsov has a post on one of my favorite hobbyhorses: making Emacs more modern. I’ve written about this several times. See here and here for example. Batsov is not sympathetic either. As Batsov notes, almost all these proposed modernizations are trivial things like “start in dark mode” or “show line numbers by default”. Others may require loading a package—such as lsp-mode or company-mode but are also easily available right now. Still others are essentially impossible (even if they were desirable) such as rewriting Emacs in some other language, which would disable the huge collection of third party packages. Finally, we have proposals to cripple Emacs by making it mouse-centric.

The thing is, most of the people making these suggestions are not Emacs users and almost certainly never will be. They’re always going to prefer an editor with glitz and bling so even if Emacs made all the changes they’re demanding, they’d still go elsewhere.

Emacs has seen tremendous progress lately with such things are native compilation and a host of lesser improvements and none of it would have been possible if the developers had spent their time making silly cosmetic changes. Batsov notes that there are plenty of “modern” editors that are less popular than Emacs so (visual) modernity is no guarantee of popularity.

Being an Emacs user is great. One of the few downsides is having to listen to the constant dirge demanding that it be modernized.