Irreal

Jürgen Hötzel has a nice post on solving a problem many of us have. Suppose you start a long running process—a make, say—from Eshell and then go on to do other work. It’s easy to lose track of the process because the original buffer may be buried and nothing might happen for a long time. Hötzel wants to be notified when the process completes or if it terminates abnormally.

It turns out to be absurdly easy to do that by leveraging John Wiegley’s alert package. Hötzel has the alert set up to show in the minibuffer but the alert package supports many different styles of alerts. For example, if you’re a Mac user and have Growl installed, you can send the alert to Growl. Another nice feature of the alert package is that you can add rules to filter the alerts. For example, Hötzel added a rule to not display the alert if the original buffer is visible. That helps cut down on noise.

Hötzel triggers his alerts by hooking into the eshell-kill-hook but it’s easy to see how you could generate many other types of alerts either by using other hooks. Take a look at Hötzel’s code; it’s very minimal and simple and mostly decides whether the alert should have “normal” status (when the process terminate normally) or “urgent” status (when the process terminates abnormally).

Bryan Willson Berry over at Hotair.tech recently moved into JavaScript development. Although he is a longtime Emacs user, he didn’t like the JavaScript support in Emacs so he moved to VSCode. VSCode is the new editor hotness, of course, so I was interested in what he had to say. I know a lot n00bs are drawn to VSCode but I wanted the opinion of someone who had experience with a serious editor.

Berry found that VSCode is an excellent editor and that it was especially good for JavaScript programming. He also found that although VSCode was better than Emacs for JavaScript, Emacs was better at almost everything else. That and the fact that he used Emacs key bindings in all his applications and therefore had serious muscle memory issues—See? I’m not the only one—caused him to move back to Emacs.

Happily, he was able to find some tools that helped with his JavaScript programming so the story has a happy ending. He still believes that VSCode is a superior for editing JavaScript but that Emacs is better in so many other ways that it makes sense to stick with it.

It’s always pleasant to have one’s biases confirmed, of course, so we Emacers probably shouldn’t read too much into Berry’s experience. Still, that experience does confirm my preconceived notion that while other editors may do this or that better, all-in-all, you can’t beat Emacs. But then, I would say that, wouldn’t I?

Rakhim Davletkaliyev is back with another Emacs Podcast. He’s got a new website and—in accordance with the cunning plan devised by the Emacs mandarins—has been seduced into using Hugo and Emacs to post to it. The plan was so successful that he’s also moved his other sites over to the same model.

After a brief discussion of the need for all of us to support those selfless souls who labor for free on behalf of Free and Open Source software, he moves on to the podcast’s main topics: Spacemacs and Doom. He gives a very balanced account of the pros and cons of each distribution and discusses why you might want to use one.

His main conclusion is that Spacemacs in particular is aimed at immigrants from the Vim world. It’s certainly possible for a n00b to start with Spacemacs but Davletkaliyev thinks that unless you’re coming from Vim it’s probably better to start with vanilla Emacs. Listen to the podcast for his reasoning about that. Even so, many beginners, after spending some time trying to grow their own configurations, may find the preconfigured environments in Spacemacs or Doom a better fit for their needs and move to one of them.

He doesn’t discuss one of the major reasons folks experienced with vanilla Emacs move to Evil, Spacemacs, or Doom: RSI problems. There’s no doubt that the Vim keybindings are much easier on your wrists than the Emacs ones are. Still, many of us have used vanilla Emacs for many years without a problem so whether or not this is an issue will vary with the individual.

The podcast is 36 minutes so plan accordingly.

In case you’re a Swiper user and missed it in yesterday’s Languages for Text Processing Post, akirakom’s Emacs subreddit post contained a tip for using Swiper. In the middle of a Swiper search you can type Meta+q to start a query-replace.

I couldn’t find that anywhere in the documentation but you can see the doc string by pulling up the documentation for swiper-query-replace. The code is here but it basically just asks for the replacement string and calls perform-replace just as query-replace does.

Over at emacs ninja, Vasilij Schneidermann talks about his number one annoyance with Emacs Lisp. Schneidermann says there are indeed problems with Elisp but he differs from most folks on what they are. He doesn’t care that it’s not fast and he isn’t worried about Emacs’ regex implementation. He’s got just two big problems with it. The most important of those is the lack of name spaces.

Schneidermann isn’t the first to complain about that, of course, but he did want to do something more than complain. He thought about using one of the packages that mostly resolve the issue but rejected them because they meant another dependency and would break his workflow. What he did instead was a sort of low tech solution that has most of the virtues of name space packages but also is lighter weight and fits in with his workflow.

His solution automates what we all do: he adds a prefix to all his otherwise global identifiers but instead of having to laboriously type them out each time, he wrote a bit of Elisp that guesses the package name from the defgroup macro and inserts it when he presses Ctrl+.. This seems like a nice solution to me, especially if you only infrequently write packages and don’t want to bother installing and dealing with another package to resolve the issue.

I’ve always found that specifying whitespace in an Emacs regex was harder than it should be. If I want anything more than a simple space (or spaces) I always have a difficult time remembering the incantation. Over time, I’ve settled on \s-, which seems to work in every case I’m interested in.

Marcin Borkowski (mbork) had similar difficulty and has a great post on what he’s discovered. The situation is more complicated than you might think but it all makes sense once you understand what’s going on. The TL;DR is that in almost every case, \s- is indeed what you want but there are some edge cases worth knowing about. Take a look at Borkowski’s post to see what they are.