Irreal

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.

Over at the Emacs subreddit, rmberYou has a post on how he uses Org mode to get and stay organized. The post is mainly a taxonomy of his Org mode files but his setup may be useful to others.

A couple of points are worth mentioning. First, he prefers a single large Org file for each general category. That’s the approach taken by Carsten Dominik¹, the original developer of Org mode. I like that approach because every thing related to a given category is one place. This is especially helpful when you’re employing reproducible research methods.

Secondly, one of the commentors notes that you should also integrate a knowledge system to record and help you remember bits of knowledge even if they aren’t actionable. I do this by recording things I’ve learned and might want later in my journal. Org mode is really good for this because of its tag system. I can simply add tags to the entry that reflect its content and then when I want it again, it’s easy to find if I can remember even one of the tags.

It’s worth spending a couple of minutes to read rmberYou’s post. He says being organized helps you deal with today’s hectic pace. I’ve found that a little effort in being organized allows me to get things done while still indulging my basically lazy nature.

Via Wilfred Hughes, I found this old post to the gnu-emacs-sources mailing list giving a quick and dirty implementation of an old Lisp Machine trick: copying a sexp that the mouse is pointing at to the position at point. Vladimir Sedach took that code and fleshed it out to a more complete implementation.

If you work with some version of a Lisp language this may be a useful addition to your toolkit. Yes, it forces you to use your mouse, which many Emacsers are loathe to do, but only in a minimal way. As Sedach says, this is often faster than repositioning the point to copy the sexp. That’s especially true if the sexp is in another window. Sedach’s method works across windows so it’s easy to copy a sexp from, say, another file as long as it’s currently displayed in Emacs.

This bit of functionality comes from the Lisp Machine so folks earning their living writing Lisp code found it worthwhile. Granted, the Lisp Machine was more mouse centered than Emacs tends to be but this seems worthwhile enough to make an exception. After all, it’s not like we’re going to be using it several times a minute.

The code does not appear to be available as an ELPA package so you’ll have to get it yourself from GitHub.

A few months ago I wrote about Luke Smith’s challenge for others to make a video convincing him to use Emacs. Among those who responded was JimKD who produced a very nice video that showcased some of the great features of Emacs. I just saw a reference to the video and watched it again. I vaguely remembered seeing it before but couldn’t remember if I’d written about it until I searched my Irreal archive. Since it was worth watching again and since there are new pointers to it, I decided I’d revisit it.

Smith is (or was) getting ready to write his thesis so one of the things he was looking for in an editor was features that made writing easy. JimKD emphasized that aspect of Emacs in his video. He begins by bringing up a buffer containing a \(\mathrm{\LaTeX}\) document and shows how it is easy to navigate to different parts of the document, show and operate on two views of the document, and compile or view the document as a PDF file. When I’m using a markup language to write, I find I often want to check the result to ensure that the markup produced the result I wanted so the preview function is important to me and probably most folks using non-trivial markup.

JimKD then moves to Org mode. His discussion is mostly focused on Org’s table editor. He shows how an Org table can behave like a spreadsheet while still being in plain text. JimKD emphasizes how important that plain text aspect is: you can always read your data even if the software that produced it disappears for some reason.

The video is just over 25 minutes but it’s interesting and well worth the time to watch it. If you haven’t seen it or haven’t seen it for a while, take a look.