Irreal

If you’ve been around Emacs for a while, you probably know that Emacs has you covered if you call find-file (Ctrl+x Ctrl+f) and specify a path with a missing directory. You simply get asked if you want to create the missing directory and give your assent with a simple Return Return.

That’s pretty simple and convenient but Bozhidar Batsov is committed to eliminating as much friction as possible and doesn’t want to have to do anything to create those missing directories. He just wants it to happen. Of course, being Batsov, he made it happen. It turns out to be pretty easy and he gives two solutions for doing it.

Almost every time I get the missing directory error it’s because I mistyped the path. That means that automating the creation of missing directories would almost always be a fail for me. But that’s me. Others, like Batsov, view it as a win. If you fall on Batsov’s side of the question, take a look at his post to see how easy it is to do.

The final, obvious, oft repeated, but mandatory observation is how easy Emacs makes it to fine tune it to each individual user’s workflow.

Bhaskar Chowdhury has a nice video on using proced in Emacs. He covers many, but not all of the things you can do with it. As Chowdhury says, proced is best thought of as a top substitute built into Emacs. I don’t think it’s quite a full blown top substitute but it does have many of the same capabilities and does move us closer to never having to leave Emacs.

As most of you know, I do most of my work on my MacBook laptop and for a long time proced didn’t really work on a Mac. But at least since 2018 it’s been working fine on the Mac. After watching Chowdhury’s video, I fired up proced to see if I could find any shortcomings—I couldn’t. Everything that Chowdhury showed worked fine on my MacBook.

Proced is perfect for a quick check on things when you don’t want to have to context switch out of Emacs. It’s just another example of how Emacs provides a nearly complete operating environment. It is as I’ve often said a light weight Lisp Machine. Most of us will never have to opportunity to work on a Lisp Machine but Emacs does provide a hint of what it was like.

Proced gives you top-like information in an Emacs buffer. That’s nice because you can use all the usual Emacs searching and navigation commands in that buffer. You many not use proced all that often but it’s perfect when you need it.

Mickey from Mastering Emacs has a post, Why Emacs has Buffers, that considers why Emacs makes the buffer concept one of its signal concepts. After all, he says, the natural construct when a programmer thinks of an editor is the string. The lines that you see on the screen are just strings and (text) files can be viewed as just a collection of strings.

Buffers, on the other hand, seem more abstract and unnatural. Mickey says they don’t evoke the same familiar associations as terms like “file” or “document” do. Of course, that’s a little overwrought. Any Emacs user, let alone programmer, who has a hard time with the concept of a buffer probably needs to find another occupation. Still, it’s worth considering why bringing the buffer concept to the forefront instead of burying
it in the internals as most editors do is the right thing and that’s what Mickey does.

One of the things the “modernize Emacs” nebbishes want to do is replace buffers with tabs. Not because tabs are better but just because they’re used to them. Of course, buffers are a much more general concept that includes things that are not files. You could, I suppose, make a tab for each buffer but that’s not want the nebbishes want: they want one tab per file just like they’re used to. I know I’m waving my cane at the kids on my lawn but—really—if you aren’t willing to put in a little effort to learn the Emacs way, please go away. If you are willing to put in that effort, welcome. There are plenty of people here willing to help you learn.

As always, any post from Mickey is worth spending a few minutes reading. Spend a few minutes to check it out.

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.