Irreal

Mike Zamansky, who is well known to Irreal readers for his excellent, some say definitive, Using Emacs Series just announced that he is planning on retiring at the end of the Spring semester. In a series of three posts Zamansky lays out why he is retiring, what he feels he’s accomplished, and what his future might hold.

Irreal has focused almost exclusively on his Using Emacs Videos but I read all his posts and several of them are interesting even if not Irreal fodder. If you’re interested in CS education and how best to train new engineers, you should definitely be reading his blog. It’s low traffic so it’s easy to keep up with.

From a purely selfish point of view I hope he devotes all his newly found free time to making new Emacs videos but realistically we’ll be lucky and happy to get one every now and then. Whatever future he decides on, Irreal wishes him the best and is happy to recognize his many contributions to Emacs and CS education.

I often read complaints about how hard it is to learn Elisp and that therefore we should rewrite Emacs in Javascript or something equally silly. The fact is, of course, that Elisp, like most Lisps, is actually easy to learn and once you’ve spend a bit of time with it, you’ve got a very powerful tool for solving text manipulation problems or, really, just about any problem at all.

Marcin Borkowski (mbork) has a short post that illustrates this nicely. Mbork’s problem is a simple one. He needs to replace all backslashes with double backslashes. That’s a trivial problem in Emacs but Mbork wants to replace only single backslashes so the obvious solutions like replace-regexp don’t quite do the job. No matter, he simply wrote a bit of Elisp that, he says, took him about 6 minutes including the inevitable debugging.

Folks are fond of pointing out, correctly, that Elisp is not the best Lisp but it’s more than good enough for its domain. Sure, things like name spaces would be nice but look at this way, part of what make Elisp so easy to learn is its simplicity.

Okay, okay: I’m weak and can’t stick to even the promises I make to myself. This is yet another post on Álvaro Ramírez’s dwim-shell-command framework. Yesterday, it was combining JPEGs into a single PDF file; today it’s killing processes from within Emacs.

I really like Ramírez’s solution but not for the reason you might think. It’s nice to be able to kill a process from within Emacs but I have almost no need to that. The reason is that I spend virtually all my time in Emacs so if any process needs to be killed, it’s usually going to be Emacs. The second reason is that when I do need to kill a process, I simply click on the Apple icon and choose Force Quit from the menu. That does require the mouse but it’s quick and easy and, most importantly, works even when Emacs is the application needing killing. Still, Ramírez’s, and your, workflow is likely different from mine so it’s easy to see how this can be a good solution.

Why do I like it, then? It’s that it’s a beautiful piece of code and shows how Elisp is well up to the task of retrieving and acting on system information that we usually think of as requiring low level system programming to get at. It’s all Lisp; no cheating by dropping into C or shelling out to a system utility. It’s very nice and well worth a few minutes of study.

I keep promising myself that I’m not going to publish anymore posts about Álvaro Ramírez’s dwim-shell-command articles but he keeps finding compelling new applications for it. The latest is a problem I often have: combining several JPEG images into a single PDF. For me, this usually comes up when I want to combine several receipt images—a bill and credit card receipt, for example—into a single PDF for tax purposes. That comes up all the time in my workflow and Ramírez’s simple application makes it easy.

Ramírez’s post is a useful one if you aren’t aware of the dwim-shell-command framework because he lists all the applications that he’s made/discovered for the it. If, like me, you like to stay within Emacs but sometimes (or often) need to run some application from the command line, dwim-shell-command is just what you need. That’s especially true if the command has a complicated, hard to remember syntax. You encapsulate all the complexity in a simple Emacs function and invoke it from within Emacs. What could be better?

Ben Simon has a post that hits two of my blogging hobby horses at once. The post is about his recent adoption of define-word and powerthesaurus. The first way it resonates with me is that Simon, like me, finally got sick of doing things the hard way and implemented a simple solution within Emacs. Like me, once he made the change, he wondered why it took him so long.

In his case, it was changing focus to Google to lookup the definition of a word or to use an online thesaurus to find synonyms. That’s just silly, of course. Emacs has all sorts of packages that will do that—and do it interactively—for you without leaving Emacs.

The second thing that resonated was the solutions he selected. Simon’s choices were the same as mine. He used abo-abo’s define-word for word definitions and Valeriy Savchenko’s powerthesaurus for finding synonyms. They’re good choices and have served me well. As I’ve related many times—most recently here—I also use the Webster 1913 dictionary (usually instead of a thesaurus) to find just the right word. As of Emacs 28, that’s particularly easy and doesn’t even require a package.

My only “complaint” is the Simon chooses to check spelling with ispell-word (bound to Meta+$) instead of just enabling Fly Spell, which automatically checks spelling. I think it’s better than using ispell-word because it finds errors even if you don’t suspect there is one. When Fly Spell finds one, you can use flyspell-auto-correct-previous-word (bound to Ctrl+;) to correct the error. It’s a nice solution that I’ve used constantly for many years.

I’ve written before about Emacs and how it fits into the Unix Philosophy. Those posts all focused on the Unix ideal of

• A program should do one thing and do it well.

The argument is to consider the one thing that Emacs does well is to handle text and consider how it uses that as a sort of universal interface. But the Unix Philosophy is more than the above. It also includes

• Write programs that work together
• Write programs that consume and output text streams

Ashton Wiersdorf also advances the notion that Emacs adheres to the Unix Philosophy but he takes the second and third legs of the philosophy as his starting point. Just as Unix can be thought of as a “tool forge” so, he says, can Emacs. It’s worth reading his argument so I’ll send you over to his post to see it. I will mention, though, that he makes the same point that many others have: it doesn’t matter too much what operating system he’s using because his main interface to his computer is Emacs and that’s the same no matter what OS lies underneath it.

Wiersdorf’s post is short and probably won’t take more than a minute or two to read so it’s worth taking a look.

In almost every case, proportional fonts are superior. They look better and they’re easier to read. One obvious exception is when programming but, even there, not everyone agrees. Still, most programmers are pretty firm in their preference for monospaced fonts when programming.

Some writers also like monospaced fonts when preparing their manuscripts, probably for atavistic reasons involving typewriters. I thought that was silly when I read it but then I realized I do all my writing in a monospaced font even though Emacs would allow me to easily use a proportional font if I wished.

All of that notwithstanding, it remains true that monospaced fonts are a bit harder to read. Blake Watson has a very interesting post on almost monospaced fonts, something that I’d never heard of before. The idea is that the characters are mostly the same size except for a (very) few letters requiring more space, like M and W, and some requiring less space like i and l. Watson’s post gives examples of the same text written in a (strictly) monospaced font and in two versions of an almost monospaced font. The almost monospaced fonts do look better and are a bit easier to read.

I haven’t tried but it probably wouldn’t be too hard to arrange for Emacs to use one of the almost monospaced fonts for certain file types or directories. Watson claims that even using them for programming isn’t bad so you could always use it as the default Emacs font if you wanted.

Don’t judge the issue without taking a look at Watson’s post. It’s interesting and revealing and you might even find that it points to another way.

Here’s a small problem to think about: how many working days are there in this month or, more generally, between any two dates? “Working days” means Monday through Friday minus holidays. It’s not a hard problem but think how you would solve it. There’s certainly no formula like that for calculating the day of the week on a given date but even consigning yourself to brute forcing the calculation there’s no obvious trivial solution.

Marcin Borkowski (mbork) has an interesting post that details his solution. His solution is for the number of working days in a given month but wouldn’t be too hard to generalize to the number of working days between two arbitrary dates. His method is truly brute force. He pushes the weekend days onto a list, adds any other days off such as holidays occurring during the month, counts the size of the list, and subtracts the result from the number of days in the month. The extra days off are specified manually so that he can add personal days off and account for differences in holidays between countries.

As Mbork says, the real lesson from all this is how flexible Emacs is and what a nice environment it provides for writing little helper functions. Take a look at his post and see if you don’t agree.