Irreal

I’m writing this on Christmas day so the festivities mean that I don’t have as much time as usual available for writing this post. Happily, I came across this post by Norman Walsh in which he mentions a fact that I didn’t know and you probably don’t either. It turns out you can define custom flags for the Emacs command line.

That’s pretty easy to do: You just add a (flag . handler) cons to the command-switch-alist variable. You can see an example of it in Walsh’s post. You might wonder why you’d want to do that. Walsh gives one use case in his post but it probably always boils down to wanting to perform some special, optional configuration when Emacs is started.

Wash’s post isn’t so much about that ability as it is the use case he has for it. It’s a short post and worth a minute or so to read.

Derek Taylor over at DistroTube has a nice introduction to reading PDFs and doing diffs from within Emacs. As Taylor says, almost all of us have standalone applications to do these things but even if you don’t belong to the Alles in Emacs camp, it’s nice to perform these tasks from within Emacs if you’re already there.

Taylor approaches the issues through his latest Emacs configuration so he discusses things like his custom keybindings that you probably won’t care about. But he does demonstrate both applications. For PDFs he uses the excellent pdf-tools package. He shows basic navigation and how to annotate PDFs. This is a great package that I use all the time. Unless a PDF comes up in my browser, it’s the only PDF reader I use.

He also demonstrates the builtin Ediff package. As I’ve written before, I’ve long had a difficult time with Ediff but Prot’s video cured me of that. Taylor’s video also helps demystify Ediff and show how easy to use if you ignore most of the fancy commands. The great thing about Ediff, of course, is that you can move any given difference from one file to the other.

It’s a nice video, especially if you’re interested in reading PDFs or performing diffs. The video is 18 minutes, 43 seconds long so you’ll have to schedule some time.

Update [2023-12-24 Sun 10:46]: Added link to video.

As many of you know, I have a long standing fascination with taking class notes in LaTeX using Emacs. This despite the fact that my days in the classroom are long over. Just a week ago, I wrote about laas, a package much like CDLaTeX that provides shortcuts for LaTeX commands to make writing LaTeX speedier.

MLStudent Odyssey has a short video that describes his system for writing LaTeX in Emacs. He’s not concerned with taking notes in class but with writing up notes after a class. His strategy consists of some custom LaTeX macros and some Emacs keyboard macros that he’s named and saved.

The macros could, of course, be replaced with a bit of Elisp but MLStudent Odyssey’s method shows that even if you don’t know any Elisp, you can still get Emacs to enter arbitrary text for you on demand.

As I say, the video is short—only 3 minutes, 58 seconds—so don’t expect a complete note taking system. Still, there are a couple of good ideas in the video and it’s well worth watching. It’s so short you should be able to fit it in without trouble.

Charles Choy has another great post documenting his never ending quest to make Emacs behave exactly the way he wishes. This post is about using Transient to call isearch.

Virtually every Emacs user knows about isearch. It’s the fundamental say of searching for strings in an Emacs buffer. But isearch is actually a complicated command with many subcommands, many of which the average user doesn’t know about. That’s bad enough but, as Choi says, the shortcut bindings for those commands are obscure in the extreme.

What to do? My solution for this sort of thing is to put together a hydra. I have several hydras that do exactly this sort of thing, although not for isearch. But there’s a new kid in town. Since Emacs 29.1 the Transient library from Magit is built into Emacs and it can provide an equivalent solution to that provided by hydra. To the end user, the two solutions look the same: you get a menu with the various choices from which you can select your desired action.

I’m completely agnostic on which solution is better. To me, they seem equivalent but I’ve seen more than one post or comment claiming that the poster never liked hydras. These claims are never accompanied by an explanation so I don’t know if they’re simple prejudice or supported by sound reasoning.

Regardless, Choi gives the code for his Transient implementation of an isearch menu so if you’re interested in a solution to the isearch complexity problem, take a look a Choi’s post.

Daniel Liden has a useful post on elementary hook functions. From the (Elisp) user perspective, there’s not a lot to know. All you need is

1. One of more functions taking no arguments. These are called “hook functions”.
2. A variable containing a list of hook functions to call. By convention, this variable’s name ends with -hook.
3. A function, add-hook, to add hook functions to the list of hooks.
4. A function to run the hook functions at the appropriate time.

It turns out there are two main functions to run hooks:

1. run-mode-hooks to run hooks associated with a major mode
2. run-hooks to run hooks not associated with modes

The existence of a special function for mode hooks raises an obvious question: “Why do we need a special function for mode hooks?” I didn’t know so of course I had to see how they differ. Run-mode-hooks is more complicated and basically takes care of worrying about doing the right thing when it’s called from a derived mode. Complicated but not too exciting.

One surprising fact that I discovered is that run-hooks is a builtin function in the C core. I always imagined that run-hooks was a simple function along the lines of

(defun run-hooks (hooks)
  (dolist (h hooks)
    (funcall h)))

The C version does essentially the same thing except that the list of functions can also contain a sublist of functions. Here it is (with the doc string removed):

DEFUN ("run-hooks", Frun_hooks, Srun_hooks, 0, MANY, 0,
  (ptrdiff_t nargs, Lisp_Object *args)
{
  ptrdiff_t i;

  for (i = 0; i < nargs; i++)
    run_hook (args[i]);

  return Qnil;
}

It could hardly be simpler so why is it in the C core? My guess is because it’s needed before the rest of the Lisp run time is established although I’m having a hard time making sense of that. If anyone knows for sure, leave a comment.

Fermin gave an interesting talk to the 2023 EmacsConf. The title of the talk was The Emacsen family, the design of an Emacs and the importance of Lisp. He starts with the premise that Lisp is the right language for Emacs implementation and extension.

That takes him to Elisp. It was, he says, a pretty nice language when Stallman designed it and today it’s still “good enough”. But that brings up the question, “Why not Common Lisp?” As we all know, RMS is not a fan but there’s more to it. When Emacs was being developed, a final specification was still 10 years away and there weren’t any (or at least any “free”) implementations available so RMS rolled his own.

But, Fermin says, we can do much better today with Common Lisp. In particular, the SBCL implementation is fast, compiles to native code, and is stable. That brings him to Lem. Lem is Emacs reimagined and implemented in Common Lisp.

The developers have made a conscious effort to make Lem familiar to Emacs users but also to make it more general and easier to extend. Take a look at the video or read to transcript for the details.

One thing I like about it is that it’s 100% Common Lisp. There’s no C core; just Lisp all the way down. That makes it easier to customize or extend any part of the editor.

It’s an interesting project but I doubt it will gain much traction among Emacsians. Using Common Lisp solves at lot of problems with Emacs but Emacs users are famously conservative about such things. Just consider the fury that a small change to how registers work provoked (see this reddit post and the Emacs-devel thread about it starting here).

In any event, it’s an interesting talk and worth watching. The video is 18 minutes 27 seconds so plan accordingly.