Irreal

I said that I was over writing about marking the active window and changing mode line colors, but, as they say, never say never. If all you want to do is change the color of the active mode line to something that stands out more than the default slightly darker gray, all you need to do is follow Ignacio Paz Posse’s advice that I described previously.

But if you want to understand what’s really going on, Prot has new video that explores mode line colors in depth. Part of the video is about how to work with his custom themes but most of it is applicable to any—or no—theme.

The video has some really useful information such as how to get a color palette of all the themes installed on your system and how to get a palette of all available colors so you can choose whatever appeals to you. He also explains the difference between the set-face-attribute command, which I used to change my mode line color, and the related custom-set-faces command which is similar but sets colors that aren’t overridden by a change of theme. See the video for more on this and how it works.

The video is just over 34 minutes so you’ll need to set some time aside but it packs a lot of information into those 34 minutes so if you have any interest in adjusting your mode line colors, it’s a must see.

Norman Walsh has an interesting post in which he discusses discovering browsing in Emacs. More specifically, he discovered how to follow a link in an Email and have the result displayed in Emacs. He’s using WebKit with Xwidgets so that means more than just using EWW.

In his setup, which judging from the screenshot is on a Mac, typing return on a link in an email renders the link in HTML in the Emacs buffer. He doesn’t say what email client he’s using but with mu4e, which I use, that doesn’t happen. Rather, the link opens in the browser. At first I thought that I must have some sort of configuration item causing the difference but I couldn’t find anything. In any event, it doesn’t matter for mu4e because if it detects you have Xwidgets installed it will automatically include a binding (ax) to render the email in HTML. From there, you can follow any other links by clicking on them.

That’s pretty nice, but it gets better. I also have elfeed-webkit installed so that I can read my elfeed RSS entries in HTML as well. What actually happens is that elfeed-webkit follows the source link in the RSS and renders it in HTML. You can configure it to automatically include or exclude specific sites if you need to.

The takeaway from all this is that it’s possible to render emails, elfeed entries, and various other links in HTML directly in an Emacs buffer. Walsh discovered one aspect of a much larger field of possibilities. Emacs has gotten pretty good at handling HTML within Emacs. There are still a few dark corners but things are getting better and better. I’m looking forward to the day I can finally ditch my browser.

Charles Choi has another Emacs nugget: how to (persistently) highlight isearch targets. The idea is that you may have a lot of hits for your search and would like to keep them highlighted so that you can examine them in detail. That turns out to be pretty simple. You simply type Meta+s h r and Emacs will exit isearch mode and highlight the text matching the regular expression. You can also highlight the entire line containing the match by typing Meta+s h l.

His post stirred a (very) distant memory so I checked Irreal and discovered that this subject is like the Phoenix: it keeps rising from the ashes. I’ve written about it at least twice, the first time in 2011, and the last time in 2022. If you check those posts, you’ll discover that there are several related commands that highlight objects in similar ways.

Choi’s post is an update to his previous post on using transient for isearch that I also wrote about. He says that although he loves the highlighting commands, he’d never be able to remember them so he added them to his transient menu.

Every time I write about this, I’m firmly convinced that the bindings make perfect sense and I’ll be able to remember them. Alas, Choi is correct. I can’t even remember that the commands exist let alone what their bindings are.

As a final point, it’s worth noting that the commands are actually a bit more general than Choi states. The isearch-highlight-regexp command actually calls highlight-regexp and passes it the current isearch target regexp and highlighting color. Similarly for the whole line variant. Thus you can highlight objects in the buffer without going through isearch. Happily, the same keybindings work in either case so if you can remember them it’s the same whether or not you’re coming from isearch.

Back in 2015, I wrote about Josh Stella’s wonderful article on A CEO’s Guide to Emacs. Someone just posted a link to Stella’s post so I took the opportunity to reread it. It seems just as apropos now as it did then.

The TL;DR is that Stella began his career as a developer and basically lived in Emacs. He used it for everything. With the passage of time he moved on from his developer role and became a CEO (of Fugue). Like CEOs everywhere, he used a multitude of applications to get his work done. But his life as a developer had taught him to eschew context switching and to value a uniform UI to the applications he needed. On day he realized that what he really wanted was Emacs so he started a small experiment to see if he really could use Emacs in his role as a CEO.

The answer, of course, was an emphatic yes and he devotes part of his post explaining why. The rest of the post is a quick introduction to Emacs and how to set it up. His purpose was to bootstrap other CEOs into the Emacs world. He was pretty realistic about this undertaking and stated up front that if you’ve never done any coding or other technical work, Emacs probably isn’t for you. But if you have, Emacs can open a world of opportunity.

Some of his recommendations are a bit outdated (2015, remember) but it has aged well. It’s definitely worth a read even if you read it back when he first published it.

Susam Pal has a nice reminder on using query-replace-regexp. Most Emacs users know about the command and its binding Ctrl+Meta+% but Pal’s post mentions some less known features that can be very useful.

The first—and simplest—is using \& in the replacement string. It expands to whatever was matched by the regular expression and is often useful.

The second feature is that you can call a function to compute the replacement string. You indicate such a function by beginning the replacement string with \, followed by the appropriate s-expr. The example that Pal gives is \,(upcase \&) which upper cases whatever the regular expression matched.

The final item involves matched substrings. Most Emacs users are familiar with the idea of matched substrings and the corresponding \n notation in the replacement string that expands to the n^th matched substring. Sometimes, though, it’s convenient to capture the n^th substring as a number. To do that you simply use the notation \#n. This is mostly useful when you are calculating the replacement string. For example, you could add 1 to the third matched substring with \,(+ 1 \#3). Pal has a couple of more robust examples in his post.

All this is, in a sense, old news but Pal’s post serves as a very useful reminder of some of the corner cases in query-replace-regexp that can occasionally save the day. Pal has a real, but simple, example of its use in his post so head on over and read it.

Of course, all this applies to the other regexp search and replace functions as well so it’s definitely worth knowing.

Jeremy Friesen has another interesting post. This time it’s about removing diacritics from a string. His problem is that he uses the same string for the title of a post as well as the name of the file containing the post but when a title contains diacritics, he doesn’t want those diacritics to appear in the file name.

To solve that problem he wrote some Elisp to replace each character having a diacritic with the corresponding character without the diacritic. For example, ç would be replaced with c. His code works fine but strikes me as being unlispy even though it’s written in Elisp.

Here, as an exercise, is my version of his code. First we need to generate the mapping between the characters with diacritics to those without. Friesen’s code produces CONS cells with the characters as strings: ("ç" . "c") for example. Since we will be replacing characters, it makes sense to keep the mappings as characters rather than strings. Here’s code to replace his code to produce the mapping jf/diacritics-to-non-diacritics-map.

(defvar jf/diacritics-to-non-diacritics-map
  (map 'list (lambda (a b) (cons a b))
       "ÀÁÂÃÄÅàáâãäåÒÓÔÕÕÖØòóôõöøÈÉÊËèéêëðÇçÐÌÍÎÏìíîïÙÚÛÜùúûüÑñŠšŸÿýŽža"
       "AAAAAAaaaaaaOOOOOOOooooooEEEEeeeeeCcDIIIIiiiiUUUUuuuuNnSsYyyZz"))

That seems to me to be much simpler than Friesen’s solution. There’s no nasty indexing into a list: map handles the whole thing.

His code to actually replace the diacritics is reasonably Lispy and his use of reduce is clever. It would never have occurred to me. Here’s what I came up with:

(defun jf/remove-diacritics-from (string)
  "Remove the diacritics from STRING."
  (map 'string (lambda (c) (or (cdr (assoc c jf/diacritics-to-non-diacritics-map)) c)) string))

If nothing else, my code has the advantage of parsimony.

Regardless of what code you prefer, Friesen’s idea is a useful one. Why have diacritics in a file name that only serve to make it harder to type?