Irreal

Here at Irreal, the minions and I are still decompressing from Christmas so this will be another short post. Troy Fletcher has a silly and lighthearted video on Emacs not being a text editor. The TL;DR is that Emacs is not (just) an editor but nearly everything else.

The video is an explication of all those other things. It’s not an editor, it’s an operating system. It’s not an editor, it’s a file management system. It’s not an editor, it’s an entertainment system… And on and on. Even though it’s a bit silly, it is a good rendition of many of the things that Emacs can do besides editing text.

The video is 28 minutes, 58 seconds long so there’s more to say than you might expect. The most distracting thing about it is that the inset of Fletcher is a split screen with two different views of him talking and gesticulating. I don’t know if that’s a normal part of his videos, a technical glitch, or another special piece of irony for the video.

In any event, if you have a half hour to kill, you might enjoy watching a video devoted to why Emacs is awesome.

I use the default mode line and am mostly happy with it except that the difference between the mode line of the active window and the other windows can be hard to discern. I know I could make myself a custom mode line like Prot did that makes the active window obvious but I’m not a fan of bling and it always seemed more trouble than it’s worth.

Still, it would be nice to have the active window clearly marked. James Dyer had a similar problem and found a nice solution. His idea was to color the left hand fringe of the active window red. That turns out to be pretty easy as you can see from his post.

Another, possibly better, solution is to set the background color of the active window’s mode line to a different color. That’s what happens now, of course, but I have in mind something a little more distinctive than slightly different shades of gray. In theory, that shouldn’t be too hard but as Prot showed messing around with the mode line is trickier than you might think.

In any event, take a look at Dyer’s post for one good solution. There are doubtless others so feel free to leave a comment if you have one.

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.