Irreal

Bozhidar Batsov over at Emacs Redux, has got another useful bit of Elisp to help clean up packages that may not have been compiled correctly. This sometimes happens to me when I update a package with package.el. The idea is to unload the function, reinstall it, and then load it again.

Batsov’s packages his Elisp as a simple function. It’s not especially user friendly because it can’t be called interactively so he provides another function that you can call with the usual Meta+x mechanism and choose the package through the completing-read function.

As Batsov says, this probably isn’t something that you’re going to need very often so you might not want to clutter up your configuration with it if you worry about such things. Even if that’s the case, you can just call the three commands separately. The require function isn’t interactive but it’s easy to call from the minibuffer with eval-expression, usually bound to Meta+:.

If you’re the type of person who hates to restart Emacs, this can be an easy way to resolve update problems without having to start over with your Emacs instance. I’ve added the interactive version to my config but haven’t needed it yet. We’ll see how it goes.

Emacs users on macOS are always discovering that the operating system supports many of the Emacs navigation keybindings and share their discovery with a Tweet or reddit post. Of course, it’s much better than that. You can install most of the Emacs editing keybindings into macOS. I first wrote about this 9 years ago and have periodically repeated the information as more and more folks discover the default Emacs bindings in macOS.

I thought that by now I and others had said everything worth saying about the matter but Álvaro Ramírez has something else interesting to add. It turns out the Ctrl+n and Ctrl+p don’t work correctly in macOS system completion lists. Ramírez has internalized the Ctrl+n and Ctrl+p bindings, especially since they work everywhere else, and was bothered by the failure on completion lists.

Ramírez found a solution from Atif Afzal. The TL;DR is that he uses Karabiner-Elements to map Ctrl+n and Ctrl+p to the down and up arrow keys. Take a look at Ramírez’s post for the details including the karabiner.json to make the mappings. He also includes a configuration to map Ctrl+g to Esc, which he finds to be useful as well.

Kieran Haley, a Sociologist at Duke has an interesting paper that provides advice on research tools for beginning graduate students—or perhaps for brand new faculty members—in the social sciences. Haley has a Uses This profile that gives a précis of his background.

It’s Irreal fodder because his primary recommendation is Emacs and R. The paper is from 2013 so it’s a bit dated—he’s using Emacs 23—but its advice is still very relevant today. Actually, Emacs provides an even better solution today than it did in 2013. This is mostly because of the growing ecosystem around Org mode. For example, John Kitchin’s org-ref addresses many of the citation problems that Haley mentions.

One of the things that that Haley calls out as very important is reproducible research and keeping your data, processing code, and text together. Org mode excels in this and provides a way of ensuring that your computed results always match your data.

If you’re just starting graduate school or an academic career in the sciences—even the social sciences—you should definitely take a look at Haley’s paper. It’s got a lot of useful suggestions and makes a few specific suggestions about tools. Emacs and Org are a steep hill to climb, of course, but very much worth the effort.

After his post on dealing with long lines in Emacs, Alain M. Lafon got a comment complaining that he didn’t mention how to profile the situation. To remedy that, he’s posted a short introduction to profiling in Emacs. If you’re not familiar with the process, you’ll be pleasantly surprised at how easy it is.

In the simplest case, which covers most situations, there are only three commands to worry about. To profile an operation, you

1. Start the profiler with profiler-start.
2. Run the operation.
3. Stop the profiler with profiler-stop.
4. Get the results of the profiling with profiler-report.

That’s all there is to it. There’s a video with the post that runs through the process for the long lines problem. The video is short (6 minutes, 32 seconds) so you shouldn’t have any problem finding time for it. As Lafon says, there’s lot of reasons you might want to profile an operation even if you aren’t an Elisp programmer. The post and video are definitely worth your time

I originally planned this as a short rant on the idea that Emacs needs to be modernized. The discussion has been raging for a while on the Emacs-devel list but was pretty much inside baseball until an lwn.net article on the discussion. Now everyone seems to be talking about it.

That’s good for me because I thought my objection to the whole thing was just another example of my innate and ever-increasing grumpiness. Hence my framing it as a Red Meat Friday post. It turns out I needed have worried. Vivek Haldar, who knows a bit about editors, reacted with a pithy tweet:

Perhaps a sign of me turning into a grumpy old guy, but everyone wants to “modernize” #emacs and it makes me scream internally.

— Vivek Haldar (@vivekhaldar) September 28, 2020

Others, such as systemhalted, had a bit more to say and suggested that Emacs is already a modern editor. Vfclists says that Emacs developers are not the type of people who will spend their time trying to make Emacs look more modern. Derek Taylor devoted an entire video to the debate. His take is that the whole thing is silly. He equates the effort to modernize Emacs with a desire to dumb it down. The problem is that the n00bs whom the whole thing is intended to attract still won’t adopt Emacs and the current users will move on.

My personal take is neatly summed up by Dragan Djuric:

Why #Emacs has different keybindings than all other editors?
Why in Emacs Ctrl+C doesn’t copy? Why Ctrl+V doesn’t paste?
Why a guitar has 6 strings while every music player has the play button?
Why an aeroplane has a cockpit? Why it’s not like my bicycle?
Mysteries of the world.

— Dragan Djuric (@draganrocks) September 25, 2020

A lot of the “modernization” suggestions are the usual silliness:

• Have Emacs start with a dark theme.
• Make CUA the default so, God forbid, n00bs will not have to enable it themselves.
• Make installing a theme (even) easier.
• Make the start screen more “welcoming.”

These are what engineers of my generation call “eyewash:” Something of no utility meant to impress the outsiders.

To be fair, some of the ideas are not so trivial but, really, I wish these people would let the developers—who are volunteers doing this for free on their own time, remember—spend their time on substantive changes as they always have. If you’re convinced that Emacs needs some sort of out-of-the-box starter configuration for n00bs, feel free to implement it. It’s not that hard. Just don’t ask our already overextended developers to do it for you.

Alain M. Lafon, whom I’ve mentioned several times before (1, 2, 3, 4, 5), has posted a useful guide for dealing with long lines in Emacs. One of Emacs’ well known weaknesses is that it can become very slow when it’s dealing with long lines. Usually this happens with programmatically generated files with extremely long lines but Lafon says that it can also happen with lines of a couple thousand characters.

Fortunately, there are some steps you can take to remediate the problem. Lafon offers several suggestions. One of the most effective strategies is to use Phil Sainty’s so-long library that I wrote about previously. Happily, as of Emacs 27.1, so-long is a standard part of Emacs so you won’t have to do anything but enable it. Even if you’re running an older version, you can still install it as a package.

Another remediation is to disable certain features of the bidirectional display facility. Unless you’re using both left-to-right and right-to-left display in the same file—see Lafon’s post for how this can happen naturally—you can reduce the number of times a lines has to be scanned by disabling some of the bidirectional capabilities.

If you’re having problems with long lines, take a look at Lafon’s post. He has several suggestions for helping to make Emacs a bit faster in working with them.

If you’re in the intersection of Gnus and Gmail users, T. V. Raman over at Emacspeak has a bit of Elisp that might interest you. He’s a Gmail user who wants to do Gmail type searches from within Gnus.

That turns out to be no too difficult and Raman shows the code to enable Gmail search syntax from withn Gnus. You can read more details in his post.