Irreal

I’ve written before about directory local variables (1, 2) and how they can be useful for setting variables or actions with a directory-wide scope. Over at the Emacs reddit, fearbedragons has a nice tip that leverages them to slightly reduce his workflow friction.

Fearbedragons has a project in which he needs to make a lot of small compiles as he goes about his testing. To help with that he set up a small .dir-locals.el file in the project directory that automatically compiles the whole directory when any file is saved. You may or may not want to do that for your own projects but the same idea works for any action that you want to take on a file event. As fearbedragons says, “You don’t always need it, but it’s sure handy when you do.”

This post is already longer than fearbedragons’ whole tip so stop reading here and go on over to reddit to take a look at the tip. It’s also worthwhile to follow his link to the dir-locals documentation to see how things work. The syntax can be a bit confusing but, as usual, Emacs can help you out by writing the entries for you. Just call add-dir-local-variable and follow the prompts. This is a useful facility that I, at least, do not use nearly enough.

I always update my Emacs packages on Sunday. I’ve found that upgrading once a week is more than enough and helps limit the ever-increasing entropy here at Irreal. This past Sunday, I noticed that there was a new Org-mode in ELPA. Because Org is central to my workflow, I’d taken to using the GNU ELPA version rather than the more up to date but maybe not quite stable version from the Org repository.

When I tried to update the packages, the update aborted because it couldn’t load the new Org-mode. It said there had been a bad request. I took that to mean that the tar file was missing for some reason or another and put off upgrading until Monday. But on Monday the same thing happened. Finally, on Tuesday I saw a tweet pointing to a reddit discussion of the problem.

It turns out that there is a problem downloading from the GNU archive that’s related to TLS. Happily, the answer is simple: just add

(setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")

to your init.el file.

Oddly, it turned out that I already had that line but it was commented out and replaced by a line that set gnutls-algorithm-priority to nil. I vaguely remember changing it to nil some months ago because of a security problem with gnutls. Presumably that’s been fixed now. I switched the commenting on the two lines, evaluated the uncommented one, and when I invoked the update function everything worked fine.

If you’re getting weird errors when you download from the GNU repository, try adding the above line to your file. It worked well for me.

One of the most constant complaints about Emacs is its reliance on finger mangling key chords forever memorialized by the “Escape-Meta-Alt-Control-Shift” backronym. Indeed, many Emacs users, including some Irreal regulars, use one of the vi emulation packages, evil, Spacemacs, or Doom, precisely to avoid those awkward key chords and the damage that they’re purported to cause to one’s wrists and fingers. Some Emacs users have even had to abandon the editor because of the strain it put on their hands.

Today’s title is due to a post from Manuel González, who like an inhabitant of Bizarro World where everything works the opposite of how it does here, says that Emacs saved his wrist. The TL;DR is that the constant switching from mouse to keyboard with his old IDE was causing him to suffer RSI in his right wrist. He tried a more ergonomic mouse, which helped a bit but still didn’t solve the problem. He decided to try an editor that could be used with just the keyboard and ultimately settled on Emacs. Surprisingly, to us here on Earth, using Emacs did solve his problem and now he’s pain-free.

The weak humor of Bizarro World aside, González’s story is interesting exactly because it goes against the conventional wisdom. My guess would be that a lot—not all but a lot—of the RSI troubles that Emacs gets blamed for is really the fault of a mouse. You don’t have to take my word for it, ask González. And do read his post; it’s an interesting story.

*Update [2019-08-10 Sat 17:41]: Fixed link to González’s post.

Kasim Tuman has a nice blog post entitled Why Emacs in which he discusses why he likes Emacs and his strategy for getting the most out of it. His viewpoint is interesting and worth reading.

Tuman thinks of Emacs as a workbench that evolves with your changing requirements to always provide a perfect fit for your current needs. One way of looking at Emacs is exactly that: it’s a workbench or toolbox for working with text. Tuman looks at it as a library for working with text. Of course, it’s much more but in its guise as an editor, that’s a good description.

Tuman takes a contrarian view by recommending that you don’t start with someone else’s configuration or with one of the prebuilt configurations. The real power of Emacs, he says, is that you can mold it to be exactly what you want it to be and to do that most efficiently you should build up your own configuration from a bare-bones Emacs. There’s much to be said for the opposite viewpoint, of course, but I take his point that if you want to make Emacs truly yours, you’re going to have to do it yourself by building your own configuration. That’s what I did—but only because there were no prebuilt configurations when I started—and it worked out well for me.

Finally, Tuman reminds us—or at least me—that the info menu command, the m key, works on any menu and that includes the top level directory node. So if you want to read, say, the Bash info file you can go there quickly and easily by typing Ctrl+h i m bash. I’m always forgetting that and doing something stupid like searching for the proper node when all I need to do is invoke menu.

There’s nothing startlingly new in Tuman’s post but he does have a unique way of looking and things and that makes for an interesting read.