Irreal

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.

As many of you know, I’ve long been fascinated by those who can write LaTeX at speed. By “at speed” I mean, for example, being able to keep up with a math professor’s lecture in the classroom. It seems almost impossible but guys like Gilles Castel showed that it could be done. Castel did his work in Vim but, of course, the same thing can be done in Emacs as Karthink demonstrates.

Castel depended on the Vim equivalent of yasnippet. Karthink also used yasnippet but his main tool was CDLaTeX. Recently, I came across a post that suggested that laas was much more efficient than CDLaTeX. I haven’t tried it but looking at the builtin shortcuts, it seems like it would be very useful for entering LaTeX at speed.

If you, too, would like to take LaTeX notes in your classes or other real time situations, you should definitely take a look at laas. And, of course, you absolutely must read Castel’s and Karthink’s posts.

My days in the classroom are long over but I was trained as a mathematician and if I were back in school today, I would definitely want to be able to take my notes in LaTeX. As I say, it seems like an impossible dream but Castel and Karthink showed that it’s possible.

Charles Choi, as we know, likes to have things the way he likes to have them. Being an Emacs user, it’s easy for him to scratch many of those itches. In his latest post, he complains about the inconsistent navigation methods for various Emacs documentation commands. They all seem to behave differently and most of them don’t follow the standard Emacs navigation conventions.

He considers, Info, Help, Man, and Shortdoc. The worst, by far, is Info. The only thing I can think of that has a worse UI is the standalone Info utility, which I consider unusable. I never use Shortdoc so I won’t have much to say about it but Help and Man seem to me to be okay, if a little inconsistent.

Choi has his own ideas of what those interfaces should be and wrote some code to implement them. It’s easy to understand and adapt the code to your own preferences. My preference is that all these Emacs functions should follow the standard Emacs navigation conventions. Since these buffers are all read-only, I’d like n and p to behave like Ctrl+n and Ctrl+p.

Some of the documentation—Info in particular—have a complicated structure the needs additional commands to navigate them. For those, I don’t particularly care what they use as long as they’re at least semi-consistent among the different documentation types.

Choi’s ideas are different from mine so take a look and see what you think. One particularly nice idea is his paragraph movement commands. He uses highlight mode to mark the first line of the current paragraph. It’s a small thing but helps you keep your place.

As usual, Choi’s post is interesting and thought provoking. Take a look just to get some ideas as to what, if anything, you’d like to do about these commands.

Protesilaos Stavrou (Prot) has an excellent short video that discusses how to use multilingual characters in Emacs. Prot, of course, is Greek and often wants to write Greek in Emacs. You can do that by switching keyboards at the system level but then—especially with languages like Greek—the Emacs keybindings break because the system is sending the wrong code to Emacs.

Happily, there’s another way: toggle-input-method bound to Ctrl+\ by default. This mode allows you to type with a non-English character set but still have Emacs perform correctly.

You can set a “default” input method that will become active when you type Ctrl+\ but if you add the universal prefix, Emacs will allow you to choose the input method you want. For example, I have my input method set to TeX so I can enter things like em dashes and various mathematical constructs but I’m currently learning Spanish so if I want to write in Spanish, I can toggle the input method to Spanish. Regardless of what input method I’m using, Emacs and its keybindings continue to operate.

Finally, there’s activate-transient-input-method, bound to Ctrl+x \, that allows you to switch to the default input method for the next character only. That’s nice for me when I simply want to add an em dash (—) but otherwise use my normal English input method. Prot uses it to add single Greek characters to his English text. As with toggle-input-method, adding the universal prefix will allow you to select the input method for the next character.

Prot’s video is 10 minutes, 59 seconds so it should be easy to fit it in. These are really useful commands even if you aren’t bilingual.