Irreal

SnipingMan18 has posed an interesting questions on the Emacs sub-reddit: How would you describe the Emacs philosophy in a single line? If you’re an Emacser, take a moment to think how you would answer that question.

My answer popped into my head almost immediately so I read all the comments to see if anyone had the same take: no one did. Some of the answers were silly, but others made a lot of sense. For example, it’s hard to argue that “the extensible editor” captures (at least one) essence of Emacs. Another nice answer was “have it your way.” That certainly captures an important part of Emacs as I’ve often noted. Another good candidate is “the DIY editor”.

All of those answers provide a good, concise, précis of what Emacs is about but none of them nail down what makes it so special to me. Regular readers won’t be surprised that my answer is “Lisp machine lite” or something like that. The point is that Emacs is not merely an editor but an operating environment to handle all your routine chores. It is, in fact, an environment for hackers to solve problems in, even if those problems don’t involve writing code.

As I’ve said many times, the only app other than Emacs that I spend significant time in is Safari. When Emacs finally solves the problem of providing a usable Web interface—sorry, EWW is not there yet—probably 95% of my tube time will be spent in Emacs.

Your answer may differ but it’s hard to argue that Emacs provides an useful and powerful Lisp environment.

The other day, I wrote about Álvaro Ramírez’s post on his Emacs theme. In a nice coda to Ramírez’s post, Aimé Bertrand writes about how he configures his UI and the functions he uses to support it.

Bertrand has some nice ideas. He’s a Mac user so some of them are meant for macOS only but others work in any environment. Among the Mac specific functions are those to switch his theme based on whether the Mac is in light or dark mode.

As he points out, switching themes can be a problem because some aspects of the previous theme can remain active. He has a function that solves this problem by first deactivating the previous theme and then activating the new one.

Another nice trick is dealing with the “warning beep”. The conventional way for dealing with this is just to set ring-bell-function to 'ignore but then you get no notification at all. You can also set visible-bell to t to flash the screen instead but many find that annoying. Bertrand solves this problem with a function that flashes the mode line instead. That’s arguably better than no notice at all but less annoying than an audible beep or flashing the whole window.

Finally, he’s got a function to propertize a string in a way similar to set-face-attirbute. I don’t have a need for such a function but I can see how it’s just what you need if, say, you’re writing a package and want to specialize the appearance of a string.

As I say, Bertrand has some good ideas so it’s worth taking a look at his post. It’s fairly short so it won’t take much time to give it a read.

Marcin Borkowski (mbork) has an instructive post based on a question in the emacs-humanities mailing list. The question that Borkowski addresses is how to replace every occurrence of a word in a buffer with its downcased version without typing the word twice. Borkowski solves this problem by writing a bit of Elisp.

In a sense, his solution is silly—as even he admits—because there are pretty easy ways of doing this with built-in commands as a couple of the respondents replied. Still, Borkowski’s solution serves as a nice example of writing a bit of Elisp to solve a simple problem.

As usual, Borkowski shows us the scaffolding. By that I mean that he doesn’t just show us a solution but the steps—and missteps—he took arriving at it. That’s why it’s an instructive post. The main thing you learn from the post is how to search through a buffer for a given regex and replace it with something else. That’s basically the interactive query-replace-regexp but you’re not supposed to call that directly from Elisp for various reasons.

Borkowski gives us the template for this sort of operation and makes it obvious how to change the operation on the target or add other steps. It’s a nice post and worth reading even if you’re already conversant with Elisp.

Because Álvaro Ramírez has been building so many useful packages and applications lately, I’ve been writing about him a lot. I’ve always thought his Emacs theme looked nice despite the fact that it’s a dark theme. The minions, of course, are tut tutting about this and demanding that the heathens be cast out but I’m more sanguine.

Although I still much prefer a light theme, it’s nonetheless true that his theme has good contrast and is readable unlike many dark themes. Now you can see this for yourself. Ramírez has posted My Emacs eye candy, which describes his Emacs theme and its configuration.

He uses the Material theme but has made many custom tweaks to it. If you must use a dark theme and don’t mind constant hectoring from the minions, his example is a good one to follow. He uses the JetBrains Mono typeface. It’s nice looking and distinguishes between zero and oh; ell, one, and eye; and comma and period. I’ve been using the inconsolata font for at least 15 years and have been very happy with it but either is a good choice.

He has many other small customizations including the execrable (sorry) Nyan Cat, tweaks to the minibuffer, the Welcome screen, and a few others. Again, if you’re looking for a nice Emacs configuration using a dark theme, Ramírez’s is a good place to start. Or you could abandon the dark side and come back to truth, light, and goodness.

James Dyer has a useful short post on indexing his init.el file. His scheme is simple. His init.el is broken into sections each of which starts with

;;
;; -> Section-name
;;

Then he used occur to generate the actual index. Rather than call occur each time with the need to provide the regex, he wrote a 4-line function that does it for him. He doesn’t say whether he bound it to a key sequence but that, of course, is trivial.

One of the commenters suggested using imenu. That’s would have the advantage of having the results show up in the echo area rather than a separate buffer but it’s not clear that that’s the right thing. You might want to visit more than one section, in which case having a (semi) persistent index is a win.

Regardless, using imenu instead would be an easy change, especially if you’re using counsel-imenu. For simplicity, though, it would be hard to beat Dyer’s short function using occur. The nice thing is that with either solution you don’t need to install anything (other than a short function): everything you need is already there.

Bozhidar Batsov over at Emacs Redux has a nice post on looking up words in a dictionary with Emacs. The post is about the dictionary.el package that’s built into Emacs as of version 28. Dictionary is a package for talking to a dictionary server and provides a way to look up words in any of several dictionaries.

In Batsov’s case he only interested in being able to lookup the word at point so he’s bound dictionary-lookup-definition to Ctrl+c l to easily look up a word but the package can do a lot more as a glance at its GitHub page shows.

I prefer to use abo-abo’s define-word package for routine word lookups because it lists the results in the echo area rather than opening another buffer. I do use dictionary.el, though, for access to Webster’s 1913 dictionary. It’s really convenient because you don’t have to install anything to use it.

As Batsov explains, you can have local a local dictionary server and dictionaries or you can use the online dict.org. Since I virtually always have connectivity¹, I just use dict.org but the choice is up to you. You can also use any other dictionary server—local or remote—that you have access to.

If you use Emacs for more than just editing code, the ability to quickly and easily look up the definition of a word is a real benefit. And, as I said, it’s already there waiting to be used.

Eli Zaretskii (did I mention he won an FSF award for his contributions to Free Software) writes to tell us that the first pretest for Emacs 29.1 has been released. The final release of Emacs 29.1 is still some time away, of course, but this is good news: it tells us that the process is advancing nicely.

As I always say, thanks so much to Eli and the rest of the developers who work so hard to keep Emacs the best editor in the world. If you run across Eli or any of the others, be sure to buy them a beer. In the meantime, if you don’t mind living on the edge, run the pretest and report any problems you find.