Irreal

I’ve written about this many times before but it’s so useful it bears repeating. It’s about a technique I use all the time and one that I’m sure the rest of you will find worthwhile too. This post is inspired by one from Alain Lafon, a master Emacs user, about whom I’ve written several times.

The idea is simple. If you’re an Emacs user and want to rename a file, the easiest way to do that is to use dired from within Emacs. But what if you want to rename several, similarly named files? The answer is the same except that you have to turn on wdired mode (Ctrl+x Ctrl+q by default). Once you’ve entered wdired mode, the changes you make to the dired listing are reflected back to the actual files. So all you have to do is turn on wdired mode and use your favorite search replace method to change the target file names. Then you simply type Ctrl+c Ctrl+c to exit wdired mode and rename the files.

Lafon’s post has an animated GIF that demonstrates the process but the easiest way to see how it works is to try it out yourself. It really is a trick worth knowing.

Yann Esposito has an interesting take on choosing tools and the choice between VS Code and Emacs. His post is from a couple of years ago but has aged well. He reminds us of a Microsoft strategy that we all knew about a few years ago but seem to have forgotten: Embrace, Extend, Extinguish. In essence, the strategy was to adopt a popular idea, extend it in a proprietary way, and then use their extended version to shut out their competitors. It’s worked well for them for many years but lately they’ve been presenting a kinder, gentler face.

Esposito is not deceived. He says that in choosing your tools you must always keep this strategy in mind. That brings us to the choice between VS Code and Emacs. Esposito has two points. First, despite the trappings of open source, VS Code is essentially a Microsoft product and there is no reason to believe that they won’t change or evolve the product in any way that they believe benefits Microsoft, even if it’s at the expense of VS Code’s users.

Second, there’s the matter of which is the better choice leaving aside the issue of its Microsoft provenience. VS Code, he says, is certainly easier to get started with than Emacs. It just works out of the box. But down the road, problems start popping up. It’s not extensible and really, really wants you to adapt to it instead of the other way around.

Emacs, on the other hand, is harder to learn and get started with, but its extensibility makes it a lifelong tool that you can adapt to your way of working. Esposito mentions Org-mode, in particular, as an example of this. It’s now part of core
Emacs but it’s worth remembering that it began life as a third party extension leveraging Emacs’ mutability. Similarly with Magit. Neither were developed by core Emacs developers but by users who had an itch that needed scratching.

If you want the easiest plug ’n play solution for your editor, none of this will convince you but if you’re a serious developer who’s willing to put in the effort to learn the best possible tool, Esposito’s post may hold some wisdom for you.

Over at EINVAL, Wojciech Siewierski considers multiple cursors (in Emacs) and whether it’s suboptimal. His post is entitled Multiple cursors considered… suboptimal, which seems rather provocative but the post is actually very even handed and concludes, as you’d expect, that whether or not multiple cursors makes sense depends on the task at hand.

I like multiple cursors and am still in awe every time I watch Magnor Sveen’s astounding demo, especially the last bit where he calculates the total time spent watching his videos. That said, I always find it a bit hard to use and, like Siewierski, usually fall back to keyboard macros. That’s probably because there’s not much to remember when using keyboard macros, whereas multiple cursors has a lot of commands and several edge cases. Doubtless, I’d be better at using them if I made a point of invoking them more often.

One of the most compelling use cases of multiple cursors for me is changing every instance of a word, phrase, or even regular expression. It’s perfect for that but I find that I generally use iedit, again because there’s not much to remember.

Still, there are some cases where you just can’t beat multiple cursors. The examples in Sveen’s video provide several cases of that. I do use and like it and should probably make a point of doing so more often so that I internalize its operation.

Chris Wellons makes a compelling case that multiple cursors is not very efficient in Emacs because it doesn’t play well with the gap buffer mechanism that is at the heart of Emacs editing. I agree with that but don’t care because, at least on the machines I use, there’s no detectable delay. Wellons has other complaints about multiple cursors that you can read about at the above link if you’re interested in the controversy but they mostly concern the edge cases where multiple cursors doesn’t work very well.

I’ve written previously about the PhD workflows of Gilles Castel and Sam Wallace. They’re Emacs based and highly efficient. Now, Tony Zorman has published his own PhD workflow. It’s also Emacs based and has several interesting wrinkles.

The most salient aspect of Zorman’s setup is that he’s using XMonad as his window manager. That provides a lot of automation and integration in his desktop. In particular, he uses the XMonad TopicSpace module to provide a separate workspace for each of his projects. Each topic space has its own directory and startup hook to provide consistent views.

He uses org-roam as a knowledge database and take notes using Org-mode but uses the usual AUCTeX/CDLaTeX combination along with aas for taking formal notes and writing papers. I’d be more reliant on Org-mode than AUCTeX for typesetting my Mathematics but I’m sure he’s used to his workflow and it seems to be working very well for him.

His post has lots of examples and animated GIFs so you can see things in action. The post serves as a great example of using Emacs and XMonad together to build a great workflow. Give his post a read if you’re interested in implementing a research workflow of your own. As I say, he has lots of good ideas.