Irreal

As I mentioned yesterday in my post about the just announced Emacs 27.1-RC2, Álvaro Ramírez left a comment to my post A Shortcut Manager for My Emacs-centric Workstation. In that post, I said that I was using yequake to pop up an Org-mode capture buffer from anywhere in the system. Jack Baty commented that yequake didn’t return to the previous application after yequake was terminated. I’d noticed that too and after a bit of research discovered that this is a macOS problem but that it could be (sort of) fixed by inhibiting Emacs from returning that the last frame when a new frame is deleted.

You can follow the discussion in the comments to the post but the TL;DR is that the fix involves a patch to frame.c. Since Emacs 27.1-RC2 had just been released, I decided to compile it with the patch and try things out. If you’d like to do the same thing, here’s the patch (against the RC2 release).

--- frame.c.orig	2020-08-07 13:54:20.000000000 -0400
+++ frame.c	2020-08-07 13:56:35.000000000 -0400
@@ -2056,15 +2056,6 @@
 		}
 	    }
 	}
-#ifdef NS_IMPL_COCOA
-      else
-	/* Under NS, there is no system mechanism for choosing a new
-	   window to get focus -- it is left to application code.
-	   So the portion of THIS application interfacing with NS
-	   needs to know about it.  We call Fraise_frame, but the
-	   purpose is really to transfer focus.  */
-	Fraise_frame (frame1);
-#endif
 
       do_switch_frame (frame1, 0, 1, Qnil);
       sf = SELECTED_FRAME ();

I said “(sort of) fixed” above because there are still two problems. First, I run Emacs and Safari in full screen mode. When I call yequake from one of them, it comes up in a different desktop. Safari doesn’t return to the Safari desktop. Oddly, with Emacs things work perfectly. The second problem is that even when yequake does return to the proper desktop, the previous application does not receive focus. Again, these problems are because of the way macOS works but the patch does help a lot.

It’s easy to try it out if you compile your own Emacs. If you get your Emacs from Homebrew, you can load the patched version with

brew install emacs-plus@27 --with-no-frame-refocus ...

Ramírez says that it should work with Emacs 26 too. Of course, if you’re not on macOS, you don’t have the problem at all.

The Emacs 27.1 train keeps rolling along with the announcement of the second release candidate. I’ve been using 27.1-RC1 and haven’t encountered any problems so I wasn’t going to bother with RC2 but Álvaro Ramírez just explained to me how to fix the problem I and others are having with yequake. That involves patching frame.c so I’ll probably use RC2 when I do that.

There hasn’t been much discussion on Emacs-devel about RC1 problems so I expect that we’re close to an official release of 27.1.

Lukas Lazarek has a very interesting post that details how he implemented his own evil-like mode for Emacs. Lazarek begins by describing the difference between Emacs and Vim. His distinction is much like mine: Vim wants to be a lightweight, fast editor and nothing else, while Emacs wants to be a text-based programming environment. I usually express that as Emacs being a lightweight Lisp machine but the meaning is pretty much the same.

Lazarek says the big advantage of Vim is its modal editing. I like modal editing but I see it as more something you’re used to rather than an actual advantage (unless we’re talking about RSI, which Lazarek does appear to be) but I don’t see it as an advantage. For me, the real advantage of Vim is not that it’s modal but that its command set is composable. I’ve written about this before.

Regardless, Lazarek wanted to implement a modal mode but didn’t want the exact Vim experience that Evil offers. It might seem like implementing your own Evil mode would be a significant undertaking but Lazarek demonstrates how simple it is by showing a short bit of Elisp that provides an “Evil mode” that merely implements the jklh cursor movement commands. It really is amazingly simple.

He also provides a link to his full implementation. It’s longer, of course, but still pretty simple and very easy to understand. That last clause is, I think, the main takeaway. It’s really easy to customize Emacs even in ways that seem complicated and outré. As always, Emacs lets you have it your way and often fairly easily.

Abrochard has an excellent short tutorial on using ERT for running regression tests on your Elisp code. Most of us, of course, don’t write enough Elisp to worry about regression tests but if you want to contribute to Emacs or an Emacs related project, it’s worth spending a couple of minutes learning about ERT.

It’s really easy to specify a test. In the simplest case you simply make one or more statements of the form

(should (equal <expected value> (<tested-function> <function-parameters>)))

and call ERT.

ERT can handle more complicated cases, including those that don’t return a value. Abrochard has a nice example of how to mock up a test when a function doesn’t return a value. Take a look at his post to see the particulars. There’s even more information in the ERT manual so take a look at that too. It’s really easy to use and there’s no reason not to take advantage of it.

It’s been a few days since I installed and starting using Emacs 27.1RC1 for all my day-to-day chores. If you follow the Emacs development list, all the items concerning 27.1 problems might lead you to think that it still wasn’t very stable but I haven’t found that to be the case at all.

By now, I’ve performed just about every one of the workflow operations that I do with Emacs and it’s performed flawlessly. The only difference I’ve seen is that Org-mode on large files is much speedier that it was before. It’s the same Org-mode so that probably means Emacs itself is faster.

I even tried EWW although I don’t usually use it much. It seemed about the same as before but I don’t have enough experience with it to say for sure. I’d really like to move as much browsing as possible into Emacs so perhaps I’ll try to use it more and get better familiar with it.

The TL;DR is that 27.1RC1 seems very stable to me, a very heavy user, and I have no hesitation in recommending that others upgrade to it. Doubtless the final version will be released soon so if you’re really wary just wait but as far as I can see there’s no reason not to start using it and help with the final testing. All you have to do if you find a problem is file a bug report, which, of course, you can do right from Emacs.