Irreal

Bozhidar Batsov, who’s been writing about Embark lately has a nice post on integrating CIDER and Projectile into Embark. I don’t use either of them so you might wonder why I care. The answer is that Batsov’s post is a good example of how to add a new application to Embark.

That turns out to be pretty easy. For projectile, Batsov built it into the app so you’ll have to check the source code to see the details. For CIDER, though, he adds the Embark functionality externally so you can see how it’s done. It’s mainly a matter of writing some straightforward wrapper functions, binding them up in a keymap for Embark, providing a target function that identifies symbols, and finally adding the keymap to Embark.

For me, then, the value of Batsov’s post is that it serves as a how to that shows you the recipe for extending Embark to include new applications.

Raymond Zeitler over at Ray on Emacs has a nice post on copying the link at point in EWW. It’s sort of hidden so that’s the reason for his post and this one. He decided to write his own because he couldn’t find anything that already did the job. It was only after he wrote it that he stumbled on the existing functionality.

The short answer is that the u key does just what he wanted. The longer answer is that sometimes w also works. The documentation says that w copies the URL of the current page but if the point is on a link, it will copy the link’s URL instead.

I’m finding that I’m using EWW more and more so I’m glad to have this information. Zeitler has more details so be sure to take a look at his post.

Sean Whitton writes to say that Emacs 31.0.91, the second Emacs 31 pretest, is now available. If you’re interested in trying it out, you can get a copy from https://alpha.gnu.org/gnu/emacs/pretest/emacs-31.0.91.tar.xz. It’s signed so you should also get the signature file from https://alpha.gnu.org/gnu/emacs/pretest/emacs-31.0.91.tar.xz.sig.

This is good news, of course, because it means that Emacs 31 is that much closer to release. There’s some great new features coming in Emacs 31 (see the NEWS file for details) so I’m looking forward to its release. On the other hand, it’s good that the devs are being conservative and trying to wring all the bugs out before the official release.

If you don’t mind living (slightly) on the edge, try it out and let the devs know if you find any problems.

Bozhidar Batsov has been a writing a very nice series of posts on recent Emacs additions that are worth knowing. His latest is on making a window dedicated. A dedicated window is one that is locked to its current buffer. That means, for instance, that if you have a particular window configuration in place and call some other function, the new function can’t hijack the dedicated window and spoil your configuration. Batsov has an animated Gif that shows this in action.

The notion of a dedicated window has been in Emacs for some time but what’s new is a quick way of dedicating a window. That way is toggle-window-dedicated, which is bound to Ctrl+x w d by default. As shown in Batsov’s Gif, that toggles the dedicated state for the current window on and off.

Sadly, I have Ctrl+x w bound to a function that starts up elfeed. I use that several times a day and have a significant investment in muscle memory so I either have to change the toggle-window-dedicated binding or simply call it directly. Since I doubt I’ll be using it that often, I’ll probably just call it directly. With my fuzzy command completion I need only enter Meta+x tog win to get the desired result.

There’s one other aspect that Batsov mentions but doesn’t explain: strongly dedicated windows. If a window is strongly dedicated, you can’t change the buffer displayed by the window. You can make a window strongly dedicated by specifying the universal argument in the call to toggle-window-dedicated.

If you like to set up a specific window configuration for some of your workflows and you don’t like random commands stepping on it, toggle-window-dedicated is just what you need.

Mode lines. Everybody complains about them and a few brave souls—like Prot—have even taken the time and effort to do something about them. The problem is that they’re so tricky to configure that it’s not worthwhile so we just suffer with the default.

Now Bozhidar Batsov writes about an easy change that anyone can make. As of Emacs 30, it’s possible to right align given elements of the mode line. That was always possible, of course, but it required some tricky padding that was particularly fragile. Now there’s mode-line-format-right-align, which serves as a marker in your mode line definition. Everything before it is left aligned and everything after it is right aligned.

Even the right edge is customizable. You can choose the right edge of the window, the left end of the fringe, or the left edge of the right margin. This facility is going to be useful to those who want a customized mode line.

My main problem with the mode line is getting all the items I want to fit on it. Even though I make liberal use of diminish, a lot of useful information always seems to fall off the right end. That probably means I need to watch Prot’s video again and buckle down to customizing it the way I want it.

In any event, it you’d like to place some items at the right side of the mode line, take a look at Batsov’s post to see how to do it.

Bozhidar Batsov has a quick post on a recent enhancement to Emacs Flymake. The TL;DR is that you can arrange for Flymake to append a diagnostic at the end of any line with a problem. It’s a quick way of seeing what the problem is and maybe fixing it without a lot of extra work.

As Batsov (and the documentation) says, that can get a little noisy so (of course) Emacs gives you a setting to control how much information is displayed. Take a look at Batsov’s post for the details.

I’ve never warmed up to Flymake but lots of people, I know, love it. If you’re one of those people, be sure to take a look at Batsov’s post. Everything is controlled by a single variable so it’s easy to try out the various options.

This feature is available only with Emacs 30 and later. Getting it may be a good reason to upgrade if you haven’t already.

As I’ve written recently [1, 2, 3, 4], I’ve been changing the Irreal Bunker’s spelling corrector to Jinx. I’ve had a couple of issues—mostly with choosing the correction—but things have mostly been smooth and Jinx has a lot of nice features.

One thing I don’t like is the face that Jinx chooses for misspelled words. Ispell used red, which stood out and made it easy to pick out the misspellings. Jinx uses a color that is almost the same as the text and even though misspellings are underlined with a wavy line they’re harder to pick out. There are two colors: one for dark themes and one for light themes. Oddly, there are no options for changing the colors.

Happily, this is Emacs so the source code is only a click away. It turns out the color is defined by a defface in the jinx.el file. I copied that to my init.el and changed the color to red Here’s the result:

(defface jinx-misspelled
  '((((class color) (min-colors 88) (background dark)
      (supports :underline (:style wave)))
     :underline (:style wave :color "#d2b580"))
    (((class color) (min-colors 88) (background light)
      (supports :underline (:style wave)))
     :underline (:style wave :color "#ff0000")) ; <-- changed color
    (t :underline t :inherit error))
  "Face used for misspelled words.")

I was going to change the color for the dark theme too just for completeness but the Minions wouldn’t allow it. You know how they are about dark themes. If you want to change the color in your Emacs, just paste the above into your init.el and choose whichever color works for you. You can, of course, also fix things up for dark themes. Just don’t tell the Minions.