Irreal

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.

Álvaro Ramírez continues to roll out new examples of applications for his dwim-shell-command framework. His latest offering is three functions that, given a photo:

1. Display the EXIF information
2. Displays the location of where the photo was taken in the minibuffer
3. Displays the location of where the photo was taken on a map

All the heavy lift is done by ExifTool. As usual with dwim-shell-command functions, the actual functions are just a little glue code that calls ExifTool and displays the results. In the case of displaying the location on a map, the lat/lon is first extracted from the photo by ExifTool and then used in a call to OpenStreetMap in the browser. It works with both macOS and X-based display systems.

The three functions, along with all the others are available in Ramírez’s dwim-shell-commands.el file. They’re all simple and easy to adjust to your particular workflow. Take a look at Ramírez’s latest post for a nice example of the power of this framework.