Revisiting The 500 Mile Email
Someone reposted Trey Harris’ famous story about the 500 mile email. The TL;DR is that Harris, working as a university system administrator, received a call from the Statistics Department claiming that they couldn’t send an email further than about 500 miles. If you know anything at all about how email works, your reaction would be the same as Harris’: Yeah right.
Oddly, though, it turned out to be true. It was the Statistics Department, after all, and they had all sorts of data supporting the claim. Harris ran his own tests and discovered to his astonishment that it was true. Email to a site closer than 500 miles worked fine. Those to sites further away than a little over 500 miles invariably failed.
I’ve written about this at least a couple of times before but it’s such a good story that it’s worth repeating now and then for people who haven’t heard it. The solution makes perfect sense once you know what it is but until you do it’s seems like an impossibility.
Take a look at Harris’ original post for the answer and for the amusing story. You may even learn a new way of thinking about network problems. Sometimes you need to look under the layer where the problems seems to exist to discover what’s actually going on.
Extracting Data From Journelly Entries
As you all know, I am always writing about how much I like and use Journelly. One of the things that I always say is that since Journelly saves it data as an Org mode file—or, if you prefer, as a Markdown file—the file is essentially a database that can be queried and processed to produce other files.
Álvaro Ramírez has a very interesting post that describes one such workflow. Much like I might do, Ramírez adds an entry in his Journelly when he comes across some data about a movie he might want to watch. It may be an IMDB entry, a Reddit post, or even just something someone told him so that all he has is the movie or director name. The common denominator is that he adds a tag such as #film or #watch to mark those entries having to do with movies he should watch. Journelly can, of course, search on the tags but Ramírez has a better way.
First he extracts all the entries having an appropriate tag into a watchlist.org file. That gives him a file with all the movies he might want to watch. He uses this and the Claude Code agent to look up each entry in IMDB and to retrieve all the metadata for each movie from IMDB and put it in a db.org file. Finally, he uses the db.org file to generate HTML so that he has a browsable file showing each movie along with its poster.
Take a look at his post for the details and to see the final results. As Ramírez says,
At the center of all it all my beloved org syntax. Thanks to plain text formats, we can easily peek at them, query them, poke at them, tweak them, and bend til our heart’s content. It’s just so versatile and now we can throw them at LLMs, too.
Almost none of this is something you’d expect a text editor to do but the Combination of Emacs and Journelly provides a way of moving from free form capture entries to a polished, browsable file.
Return Of The Prodigal Son
Well, not really prodigal, but the return—nonetheless—of a son assumed lost. Michał Sapka has a blog post about his return to Emacs. A while ago, Sapka left Emacs for Vim and the shell. He liked them but realized that Emacs really is different.
The way it’s different is telling. Although you can do anything in Vim and shell, Emacs is different. As Sapka puts it,
It’s not that nothing stops you from connecting Mastodon.el, Magit and Mu4e, it’s that it’s natural.
Because all of Emacs is exposed to the user, it’s easy to modify it to fit your workflow and string together disparate applications in ways that their authors never intended. Sapka makes the same point that Irreal and others have made: it’s not that Emacs has an extension language, it’s that Emacs’ source code is modifiable on the fly from within the application itself at run time. It’s a whole different thing.
Sapka admits that there are problems but says that they are solvable. Depending on your work environment, solving them may be more or less difficult but they remain solvable.
In any event, Sapka has returned to Emacs because, in the end, nothing else provides the same power and flexibility. He ends his post by noting that he’s—sort of—combined the power of Emacs and Vim by adopting Evil mode.
Kitty Cards
Álvaro Ramírez and Vaarnan Drolia have introduced a really interesting app. At least I guess you would call it an app. It’s actually just a Web page that lets you build your own custom Apple Wallet cards. It’s easy to use. You simply bring up the Web page, click on and fill in the fields you need on the sample card—including scanning for a bar code—and click on the “Add to Apple Wallet” button.
If you’re an Apple Wallet user, you may like this app. You can take any physical card with a bar code and add it to your Apple Wallet. Then you have one less card to carry around.
Gruber On File Saving Ease
John Gruber, over at Daring Fireball has a post, Untitled Document Syndrome, that makes two points of interest to Irreal readers. The first involves the difficulty of initially saving what he calls “untitled documents”. He’s writing about macOS, of course, but even through I’ve used one Mac or another for almost two decades, I had a hard time figuring out what he was talking about. I guess it’s this: in some Apple text apps you can start typing without specifying a document name or a file path for where it should be saved. That means that when you first save the file you have to negotiate the file save dialog to supply this information.
Since I write everything in Emacs, this never happens to me. Part of starting a new file is executing a find-file which specifies its name and file system location. Even then, I just specify it in the minibuffer; there’s no annoying open dialog to deal with. The first time I save it is like any other time1: a simple Ctrl+x Ctrl+s.
The point of all this is that the difficulty of the initial save means that people will put it off and therefore suffer disaster when the app or system crashes. They may even lose hours of work. Happily, that first save is easy in Emacs so there’s no reason—not even a weak one like the save dialog—for putting it off.
Even if you do put it off, Emacs, like Gruber’s editor BBEdit, has you covered. It does periodic automatic backups so you never lose more than a little work.
The second point is related and concerns note taking apps. Like most of us—at least us oldtimers—Gruber stated taking notes by creating a file for each one with his editor. As we’ve all discovered, that doesn’t work all that well so he moved to Yojimbo and discovered that he was taking many more notes. As you all know, I solved the same problem with Journelly. I use it as my memo book and typically make about 10 entries per day. People think of Journelly as integrated with Emacs but it can also save its data in Markdown so it’s perfectly usable on any system and editor as long as you’re using an iPhone.
It’s amusing how 40 year old technology is still more convenient and easier to use than “modern” systems with dialog boxes for everything.
Starting A Journal
A couple of weeks ago I read a lovely story in The New Yorker by Calvin Tompkins about starting a journal in his hundredth year. Tompkins was born the same year that The New Yorker was founded and, ironically, spent most of his working life writing for the magazine. Last year—his hundredth—he surprised himself by deciding to start a journal as a sort of countdown to his hundredth birthday. The story is mostly entries from the journal but I found them fascinating. Perhaps you will too. If nothing else, you’ll get a first hand glimpse of what old age really looks like. The TL;DR is that there’s good news and bad news.
In any event—although I am nowhere near my hundredth year—I was inspired to start my own journal. Of course, it was going to be written with Emacs but the question is how. There is the builtin journal app as well as some third party packages but I chose simplicity. I didn’t need anything special or complex with arcane functions so I just added an Org capture template to create a file+datetree file in Org mode. Here’s the whole thing:
("J" "Personal Journal" entry (file+datetree "~/org/personal-journal.org") "* %<%R: >%? \n%t" :empty-lines-before 1)
I have some startup options in the file itself to set visual-line-mode, use a variable pitch mode, and couple of other things: the same setup that I use for my blog posts. All this is simple and familiar. There’s nothing new for me to learn since it’s basically the same setup that I use everyday to write my Irreal posts.
The takeaway is that if you’d like to start a journal, it’s really easy. Just use a simple Org file with a corresponding capture template.
Emacs Performance on macOS
Does Emacs run slower on macOS than it does on a similar machine running Linux? I don’t know. I’ve been running Emacs almost exclusively on macOS for somewhere around 17 years so its performance on macOS, whatever it is, seems normal to me.
Over at the Emacs reddit, staff-engineer says that he runs it on both macOS and on Linux. The Apple machine is, in fact, more powerful than the Linux one but is nevertheless less performant when running Emacs and staff-engineer wonders why.
He received several excellent answers that are definitely worth reading but I especially like the one from totbwf who explains that a large part of the problem is that macOS uses a tiny size for its pty buffers and that this can significantly slow down Emacs when it calls an external process using a process-connection-type of pty. His solution to this is to simply advise functions calling start-process to use pipes instead of ptys. He says that this can speed up these actions by a factor of 10. For Magit, he says that you can get the same result by simply setting magit-process-connection-type to nil.
Even if you don’t want to add a lot of advises to your configuration, it may be worthwhile making this one simple change to Magit if you use it a lot.
To be honest, I have no idea if these fixes will work or not but they’re easy to try if you feel Emacs is too slow on macOS. If changing the connection type helps, I would think that someone would fix it in Emacs core for macOS installations. It doesn’t sound like it would be too hard but one of the problems is that there are few Apple users helping with development.
Microsoft 365
I was going to make the fact that Microsoft 365 and other Microsoft tools are down into a Red Meat Friday post with a title that included the word “schadenfreude” but my better nature prevailed and I forebore. Today, though, I saw this: they’re still down. To be fair, it appears to involve more than just Microsoft so it’s probably a network issue of some sort.
Nevertheless, this inconvenient fact remains: if a critical part of your company’s workflow depends on an Internet connection to operate you really should reconsider your decisions. Sometimes, an Internet connection is unavoidable but it certainly shouldn’t be for basic operations like word processing. Who benefits from the need for an Internet connection? Hint: it’s not the user.
It doesn’t have to be this way. There are plenty of open source office suites that are free to use and don’t require calling home to work. There are many companies and even governments that are using them today.
The whole thing reminds me of the old adage that “No one ever got fired for choosing IBM”. It was never true, of course, but it did express the widely held sentiment that IBM was the safe bet. The same doubtlessly holds for Microsoft but it’s even less true for them. Their software in no more robust—often less robust, in fact—than their competitors’ offerings that aren’t phoning home all the time to check your subscription or make sure that what you’re writing meets their terms of service as Google Docs famously does.
The general rule is easy to state. Anything critical should operate—and most importantly, store data—locally. Sure, some apps will need a connection to complete their task—WordPress for blogging is an example—but they shouldn’t need that connection just to start using the application.
Of course, I’ve been preaching this for years and people still aren’t listening. I don’t expect that to change. To be clear, I don’t insist that you have to use open source software, only that if the Internet goes down or the company goes out of business, you can still get your work done.
Casual EWW
You’ve all heard me moan many times about my failure to bring my last remaining significant application—Web browsing—into Emacs. There are some solutions but none of them come close to being sufficient. If you want full featured browsing, you’re mostly restricted to Safari, Firefox, one of the niche browsers, or the privacy violating Chrome and whatever Microsoft’s browser de jour is called.
Still, there is EWW, which some people find some sufficient for a subset of browsing tasks. Charles Choi is one of those people so naturally he’s made using EWW easier by adding Casual EWW to his Casual Suite.
You can read his announcement for the details but, as usual, it’s mainly a set of transient menus that make discovery and remembering obscure commands easier. As I’ve said before, even if you need only some of the apps, it’s worthwhile installing the Casual Suite.
When Should You Use Visual-line-mode?
Over at the Emacs subreddit, floofcode complains that he doesn’t like the way visual-line-mode handles moving from line to line. He found that everything worked fine without visual-line-mode so he wondered when is visual-line-mode useful.
If you read his post, you’ll notice that he had visual-line-mode turned on globally. That explains a lot of his frustration. As nice as visual-line-mode can be, you definitely don’t want it enabled all the time. It would be a disaster when writing code, for example.
The thing about visual-line-mode is that it considers all the text between line feeds to be one long line and soft wraps the text to fit your screen size.That’s useful even when you’re just dealing with text locally but I find it essential for my blogging. If I set a hard line size, it gets carried onto my blog and really messes up the displays of people with smaller screens or windows such as those reading Irreal on a phone. With visual-line-mode, the text gets flowed to fit the target screen.
So the answer to floofcode’s question is that visual-line-mode is definitely useful but mostly when you’re writing prose such as in Org-mode. I use it whenever I’m writing prose but never when I’m, say, programming or using some other specialized Emacs mode. For instance, I don’t use it in my Org based tax files because they’re mostly tables and don’t include long sequence of text. I generally set it on a per file basis except for my blog where a hook recognizes blog posts and sets it and some other appropriate modes.