Irreal

Emacs Elements has an informative post on how to escape from a recursive edit. Unless you’re already an advanced user, you probably have only a vague notion of what a recursive edit is and you certainly aren’t going to be intentionally entering one. But, unfortunately, it’s fairly easy to stumble into one.

Even when you deliberately enter a recursive edit—the video has a typical use case—you still need to know how to exit to the main edit. The standard way to get out of a recursive edit is Ctrl+Alt+c but sometimes Emacs get wedged—especially when you inadvertently find yourself in a recursive edit—and you need to force an escape to the top level.

The video demonstrates several ways of doing this so you should definitely take a look but a good rule of thumb—although not a complete answer— is to try

• Ctrl+g
• Ctrl+]
• Esc Esc Esc

in order.

There are, as I hinted, a few nuances so be sure to take a look at the video for the complete details. The video is only 8 minutes and 21 seconds so it should be easy to fit in.

Update [2023-11-23 Thu 11:41]: Existing → Exiting.

Michael Neuper has a very nice article on Efficient LaTeX Editing With Emacs. As far as I know, there’s only two reasonable ways of doing that:

1. Org Mode
2. AUCTeX

Org mode is good for what might be called “light weight” LaTeX. If there’s a minimum of mathematics and special formatting, Org is ideal. Its simple markup is easy to learn and you don’t to need to worry about the more difficult LaTeX syntax. The result is exported to LaTeX so you can add LaTeX formatting as needed and the resulting PDF is still produced by LaTeX so you get the beautiful typesetting that the TeX family promises.

If you need more heavy duty mathematics and formatting, it’s hard to beat AUCTeX. It is, after all, purpose built for writing LaTeX inside Emacs. Neuper concentrates on AUCTeX and shows how to augment it to obtain an efficient LaTeX writing environment.

For AUCTeX itself, he starts by showing how to get a live preview within Emacs. If you’re like me and like to see how the output of a long document is progressing as you write, this is a Godsend. A couple of keystrokes and the current document appears right there in a separate Emacs window. What could be better?

He also looks at using special symbols (in the LaTeX source) and folding. I don’t think those are as important as live preview but some may find them useful.

His next addition is CDLaTeX, which I’ve written about before. It provides some shortcuts for entering LaTeX commands and symbols. It’s also usable inside Org—or anywhere in Emacs, really—so it’s definitely worth knowing about if you write LaTeX, even in Org.

Next he looks at using LatexMK and LSP. Most TeX/LaTeX users know about using LatexMK to make sure forward references are resolved. I didn’t know there was as LSP engine for LaTeX but apparently there is. If you care about such things, Neuper shows you how to set it up.

Xenops is a package that I haven’t heard of before. It basically serves as a sort of in place replacement for live preview. Take a look at the animated GIF in Neuper’s post for a demonstration.

Finally, he considers YASnippet and Calc. Both of these are able to expand some simple text into more complicated LaTeX. The Calc example—also illustrated with an animated GIF—is especially revealing. I vaguely knew you could do this sort of thing but I’ve never seen it in action before. Very nice and very powerful.

If you write in LaTeX at all it’s definitely worth your while to take a look at Neuper’s post.

Ruslan Bekenev has a post on filtering the results of buffer listings that reminded me of something I’ve known since I started using Emacs but keep forgetting. Bekenev writes that he often lists the open buffers with Ctrl+x Ctrl+b mostly so that he clean up his Emacs environment by deleting no longer needed buffers. I used to do the same thing so I can sympathize with the urge.

One day, though, he wanted to filter the listing so that only buffers from his current project were listed. Sadly, list-buffers is pretty bare bones and doesn’t support filtering. Ibuffer does, though, and produces essentially the same output as list-buffers. My first thought was, “that’s neat” but I also felt that it seemed familiar.

It was, of course. Long ago when I first started using Emacs, I learned that I should use ibuffer instead of list-buffers. I last wrote about this only a year and a half ago but I’d already mostly forgotten how powerful ibuffer is. Every time I rediscover the filtering capability, I promise myself I’ll internalize and make regular use of it but the truth is I just don’t need filtering often enough for the habit to set.

In any event, ibuffer is a better version of list-buffers and well worth trying. As Mickey says in the above link, “You should switch to it right now.”

Protesilaos Stavrou (Prot) has a really excellent video on Ediff. I’ve always had a difficult relationship with Ediff. It seemed really complicated with lots of obscure commands and, by default, a control panel that resides in a different frame, which didn’t play well with running Emacs full screen as I do. I’d already resolved that last problem but for those of you who haven’t, Prot shows you the secret spell.

More importantly, he demonstrates that using Ediff is actually simple if you ignore all the obscure stuff. With his configuration, the two (or three) diffed files or buffers are shown side by side and a short buffer at the bottom serves as the control panel. By default, the full panel with all the commands aren’t listed—although you can use ? to toggle it—but prot says that doesn’t matter because you hardly ever have to use that other stuff. All you really need to know is n for the next diff, p for the previous diff, and a, b, or c to move the A, B, or C diff to the other buffer(s). That’s it. It covers almost everything you ever really want to do in Ediff.

Prot also demonstrates the Magit Ediff (dwim) command that lets you see how a particular file has changed over a series of commits. It’s easy to use and invoked right from Magit.

Finally, for those who want to configure their Emacs like Prot does for Ediff, here are the two commands you need for side by side buffers and the control panel in the same frame at the bottom:

(setq ediff-window-setup-function 'ediff-setup-windows-plain)
(setq ediff-split-window-function 'split-window-horizontally)

I found this video to be really helpful. Perhaps you will too. The video is 15 minutes, 48 seconds long so you may have to schedule some time.

Mario Jason Braganza has an interesting post that opened my eyes to another way of adapting Emacs to your workflow. I’m a programmer so my first impulse when I have a problem to solve with my workflow is to write a program. That works well for me. It works especially well with Emacs where it’s easy to write a quick function to sand down any friction with in my workflow.

The first thing Braganza did every morning was to manually configure Emacs to show his notes and agenda in a single frame but he wished there was a way to make this happen automatically. He realized that the easiest way to do that was to write a bit of Elisp but he had neither the the time nor the inclination to learn Elisp so he looked around for another way.

His solution was to do it by hand but record his steps as a keyboard macro. Then he could save the macro and simply replay it every morning to get his desired Emacs windows configuration. He had a couple of problems but eventually got everything working.

Like most experienced Emacs users, I often use keyboard macros to automate a one-off task but I never considered using them as a substitute for Elisp. Why would I? I can write Elisp but for those who can’t—and sometimes even for those who can—macros are a really nice way of automating some frequent task. It’s yet another way that Emacs adapts itself to its users rather than insisting those users adapt themselves to Emacs.

Marcin Borkowski (mbork) has a cute post that addresses the abomination known as camel case. I use the term camel case to cover actual camel case as well as any of its illegitimate siblings such as studly caps. As I’ve said before, it makes text hard to type and hard to read with no discernible benefit.

Someone on the Emacs mailing list suggested coloring camel case identifiers so that all the odd subwords are in one color and all the even subwords in another. Borkowski took the idea and ran with it producing a proof-of-concept mode based on glasses mode. It turned out to be easy, at least for the simple cases. One thing I learned from his post is that of version 29.1, the overlay implementation was rewritten making it faster.

For me, the takeaway from Borkowski’s post is not a way of making the horror of camel case marginally more legible. It’s about how easy Emacs makes it to implement even a seemingly difficult feature. Or for that matter, to implement it at all. As I said, I have no interest in tinkering with camel case but I love how Emacs makes it relatively simple to tinker with even the seemingly low level display features. Zamanky’s ongoing project to replace certain words with an emoji is another example of this. The emojis are displayed instead of the keywords but the underlying text is unchanged.

Overlays are a powerful technique built into Emacs that can be used in all sorts of projects as Borkowski and Zamanky demonstrate.

Martin Edström has announced a new package: massmapper. The idea is to make it easy to—for example—copy all the Ctrl– bindings to Super-. That’s a real pain if you try to do it piecemeal by hand but massmapper makes it easy.

The above is pretty much the TL;DR. To get a better idea of what it does and how it works, take a look at the README from the GitHub repository. That lists all the commands, which gives you a good idea of what’s possible.

There’s a lot of dark corners in this enterprise and judging from the README, Edström has considered them and either made allowances or documented the ones that can’t be fixed. An example of that is Ctrl+g, which is hard coded in Emacs and can’t be changed. There are a few other things like that but mostly it “just works”.

I’ve never felt the need for mass rebindings: indeed, I don’t think I rebind any keys but lots of people appear to consider it an important part of making Emacs work for them. As usual, Emacs lets you have it your way. In this case, not directly, but by making it possible to write a package to do it for you.

Sandra Snan over at Idiomdrottning has posted a link to some very idiosyncratic functions that seem at first to be useless or even silly but may, on second thought, actually be useful for some applications. The idea is that they’re like replace-regexp but have the regexp predetermined. The functions are:

• replace-word
• replace-line
• replace-paragraph
• replace-var
• replace-sentence

and they replace every instance of their target. For example, replace-word will replace every word in the target area with the substitution value. That doesn’t sound very useful but you can use & to substitute the match in the replacement. Snan has some examples in her post.

Again, these are low use functions but certain workflows may find them and the saving of entering a regexp useful.

I’m running a little experiment. Even though I recently realized that I hardly ever use a terminal emulator, I was intrigued by this shoutout to the eat terminal emulator package. Except for the usual ankle biters, who don’t appear to have even used the package, the comments were all very supportive, some even saying that it significantly enhanced the commenter’s workflow.

I checked the README at the project’s GitHub repository and I was again impressed. It’s pretty speedy considering that it’s implemented in Elisp. It has several modes. One of those modes lets you move around the buffer and use the usual Emacs editing commands. That’s something that’s missing in vterm so it seems an improvement.

Installing eat is a simple one step process using the package manager. After that, you simply invoke it with Meta+x eat to start a terminal.

As I said, I don’t use terminal emulators very much anymore but I am going to try to use it as much as I can. I still have to refer to the README for the keybindings but I’m sure they’ll soon be absorbed into my muscle memory. There is, in any event, a manual (also available in Info) that covers everything. I’ll report back later with my impressions after I gain a bit more experience with it.