Irreal

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.