Irreal

Mickey from Mastering Emacs has an excellent post on the various ways of evaluating Elisp in Emacs. As Mickey says, there are several ways of doing it depending on the context and it pays to be familiar with them all.

The most familiar way is probably eval-last-sexp (Ctrl+x Ctrl+e). It’s really useful because it will evaluate almost anything: s-expressions (of course) but also numbers, strings, and most special forms. The situation for special forms has improved a bit in Emacs 28 so be sure to take a look at Mickey’s post to get the details.

There’s also eval-buffer and eval-region, which do as their names suggest. These commands generally don’t evaluate special forms such as devar, defface, and defcustom. That’s generally what you want so it’s a feature instead of a bug. Again, see the post for the details.

The method that I always tend to forget about is eval-defun, bound to Ctrl+Meta+x. It’s especially handy for evaluating functions because, unlike eval-last-sexp, you can call it from anywhere within the function instead of needing to be at the end. If you call it with the universal argument, it will turn on debugging for the function. It’s worth reading Mickey’s article just for the section on this command.

Finally, there’s Eshell and IELM. Most Eshell users know you can evaluate many Elisp expressions there but when you want a real Elisp REPL, IELM is what you want. It’s perfect for experimenting with code that’s longer than a single expression. I use it fairly often and love it.

Like all of Mickey’s posts, this one is definitely worth your time and effort.

Yi Tang has an interesting post on the dired-rsync package. It’s been around for a while, apparently, but I hadn’t heard of it before Tang’s post. The TL;DR is it allows you to use rsync in dired in the same contexts that you would otherwise use Copy.

Tang lists all sorts of reasons why he believes rsync is superior to cp and scp but, oddly, doesn’t mention the major one: rsync only send the parts of the file that are different from the target. It is, in short, a tool optimized for copying an updated file.

Much of the post is devoted to explaining how Tang has integrated the package into his workflow. It’s perfect for downloading large data files from a server to his local machine where he can manipulate and analyze them. He explains how he set everything up in case you have a similar use case and want to recreate his workflow.

It’s a nice post that also explains some of the gotchas if you want to use dired-rsync yourself. It’s on Melpa and setting it up is simple. You can simply copy Tang’s use-package configuration for an excellent starting—or permanent—setup.

Karthik has a nifty video on how to change the way Emacs works. We’re all fond of saying that Emacs is infinitely extensible and customizable but then we usually go out for a beer without saying how. Kathink remedies that by showing us how to change Emacs’s behavior even when we don’t know what we’re doing.

Kathink uses Notmuch to read his email from within Emacs but he’s got a problem. He’s a developer so a lot his email includes a patch or a diff as a MIME attachment. That’s fine but most of the time he doesn’t want to see large patches or diffs. What he’d like is for those two MIME types to be folded by default so that they don’t clutter up his emails but so that he can unfold them when he does want to see their content.

He begins by saying he has no idea how Notmuch works but he doesn’t let that stop him from resolving the issue. What follows is his step-by-step discovery of how to solve his problem. He beings with the usual checking of the documentation and customize subsystems but, sadly, that was of no avail. Instead, he had to turn to the source code.

Notmuch has a lot of code, none of which he’s familiar with so it seems like an impossible task but Karthik shows definitively that that’s not the case. He doesn’t use a debugger or any fancy tools; he just burrows around in the code until he zeroes in on the solution. His method resonates with me because it’s pretty much what I do. Most of the time I don’t really know exactly where I’m heading but just follow the clues until I arrive at the solution. That’s exactly what Karthik does.

The video also demonstrates somethings that I already knew but didn’t appreciate enough until I saw them in action. The first of those is using xref-find-defintions to navigate through the code. The second is setting what Karthik calls “pins” to remember locations so that you can return to them at will. He does that with point-to-register to set the pin and jump-to-register to return to it.

This is a really good video and I recommend it to all Emacs users. It’s 29 minutes, 44 seconds so plan accordingly but do try to find the time.

Update [2022-08-01 Mon 13:10]: Work → Works

Álvaro Ramírez has been busy making improvements to his excellent dwim-shell-command package. I’ve written a lot about this package recently but that’s okay because it’s something most Irreal readers would want to know about. The TL;DR is that the package provides a DWIM interface between Emacs and the shell making it easy to invoke various utilities from Emacs that would normally be started from the shell.

The new version allows dwim-shell-command to operate on a set of files in a region rather than having to be marked in dired. There’s also a marker to insert the contents of the clipboard into a command. That’s perfect for inserting a URL that you’ve clipped from, say, the browser and using it in a shell command.

Finally, Ramírez has added numeric and alphabetic counters that allow for names that are the same except for the counter value. That works just as you’d think it would. The package is, after all, meant to provide do what I mean actions.

As far as I can see, this package started out as a quick hack that allowed Ramírez to create an easy way of invoking frequent but complex shell commands. Once he’d laid down the framework, new applications kept suggesting themselves to him and the project has grown.

As I wrote the other day, the package is now available on Melpa so it’s easy to try it out if you’re interested.

Torstein Johansen has a short video that addresses the question of why he uses Emacs in 2022. The backstory is that every time he takes a new job or consulting position, the incumbents—who all use things like IntelliJ, Eclipse, or even VS Code—stare in disbelief when they see he is using Emacs and lecture him on how much more efficient he could be if he was using a Modern Editor™.

Johansen disagrees. Maybe, he says, there isn’t a button in Emacs to automatically refactor a section of code—although such a thing could be, and perhaps has been, implemented by any user who feels the need—but what Emacs offers is speed. Speed in the sense of being the shortest path between your brain and what appears on the screen.

Johansen also makes the familiar point that Emacs has a consistent set of shortcuts that work for virtually all the packages that run inside it. Those shortcuts allow efficient navigation of editing of whatever buffer happens to have focus. He notes that this is so comfortable that Emacs users typically try to stay within Emacs as much as possible.

This leads to the well-known phenomena of Emacs users trying to migrate as many tasks as possible to within Emacs. Johansen considers himself “a bit out there” because he handles his email from within Emacs. I found that amusing since I do the same and more. As I said many times, virtually all my tube time is spent in either Emacs or the browser and I’ve migrated as many Emacs shortcuts as possible to the browser and other macOS utilities.

The kids can say whatever they want about their fancy editors but the fact remains most serious programmers use Emacs or Vim.