Nicolas Petton writes that the first pretest of Emacs 26.3, 26.2.90, is available for download and testing. If you don’t mind living just a little bit on the edge, download and help with the testing.
As always, thanks to John, Eli, Nico, and all the others for shepherding the ongoing development and improvement of Emacs.
A couple of weeks ago, I wrote about the Equifax and First American Financial Corp breaches. I noted that the situation was out of hand and that even the curmudgeons at Irreal were ready to put aside their distaste for government intrusion into our affairs and demand that they mandate severe and certain penalties for companies that collect our information and then fail to protect it.
It turns out, though, that the government isn’t any better at safeguarding the data they collect—often involuntarily—from us. Customs and Border Protection has been rushing to put its program to gather biometric data into place but apparently hasn’t devoted much thought into protecting that data. The CBP announced that on May 31, 2019 they learned that one of their subcontractors has suffered a breach and lost a database of photos of travelers and scans of license plates. The extent of the loss isn’t known but, of course, the CBP is “taking the incident very seriously.”
“Very seriously” is the same old refrain we always hear from people who couldn’t be bothered to protect the information they gather about us. I haven’t read anything about anyone being fired or about contractors being terminated1. No, “very seriously” means “We’ll pretend to do something but really won’t. Now move along and don’t bother us anymore. We’ve got data to collect.” And, indeed, CBP is pushing to expand their biometric data collection programs significantly.
Understand that this isn’t data collected from known suspects or trouble makers. It’s data from everyday citizens just like you and me who happened to be unlucky enough to use an airport that already had the program in place. It’s bad enough they’re collecting it but it’s intolerable that once they did they couldn’t be bothered to safeguard it. It’s fine to blame “a contractor” but we here at Irreal say, “You collect the data, you own the responsibility to protect it.”
Remember this story the next time the FBI or some other government agency says they need a private key to your data but don’t worry, they’re the government and can protect it. They can’t. If not even the ultra-secure NSA can do a credible job of protecting their data, you can be sure the other agencies won’t be able to.
Quite the contrary, the CBP tried to protect the identity of the offending contractor but couldn’t manage even that competently. See the linked Wired article for the details.
Bastien Guerry tweets that Org-mode has a new release.
#emacs #orgmode 9.2.4, a bugfix release, is out. Enjoy!
— Bastien Guerry (@bzg2) June 11, 2019
As usual, thanks to Bastien, Nicolas, and the others for all the work they do for us.
Unix is often credited with being the first portable operating system because it was written in a higher level language and could relatively easily be ported to new machines. That portability changed everything. But this post isn’t about Unix; it’s about Emacs.
It’s almost a cliche to make the case that Emacs has more in common with an operating system than it does with an editor. Here at Irreal, our favored comparison is with the Lisp machines from the 1980s. Emacs isn’t an operating system, of course, nor is it really a Lisp machine but one thing it is is portable. By that I mean that you can take your Emacs environment with you regardless of the OS or machine you happen to be working on. If, like many of us, you do almost everything in Emacs, you end up with what amounts to a portable operating system, or at least a portable operating environment.
Again, that’s hardly an original thought but it was brought home to me last week because of WWDC. As most of you know, I live (happily) in the Apple ecosystem and like it for reasons that I’ve discussed before. But after reading about all of Apple’s neat new features coming to the Mac and iOS (and now ipadOS) apps, I realized that I didn’t really care. Not because I thought they were uninspired or boring—quite the opposite—but because nice as they were I wouldn’t be using them since most of the new functionality exists in some form in Emacs.
Consider the Reminders app. It exists across Macs, iPhones, and iPads and is already quite nice. Apple is making significant improvements to it in the new releases of the OSs this summer but the thing is, I do all those chores with Org mode and if I need some special capability, it’s easy to just add it so I won’t be using Reminders’ neat new features. The same thing applies to many of the other changes: They’re nice but Emacs has me covered and it has me covered regardless of what machine I happen to be working on. As a wise man said, “I don’t care what OS I use because…”
Now if we only had Emacs for iOS and ipadOS.
Xah Lee recently tweeted out a reference to one of his old pages on Emacs Lisp. This one considers specifying Unicode escape sequences in Emacs strings. It’s a handy guide and well worth giving a look. Doubtless, you could find the same information in the documentation but Lee’s page is a useful guide, especially since most of us won’t need the facility very often.
The TL;DR is that if you want specify a Unicode character in an Emacs string, you can either insert it directly like this: “Here is the Unicode character 😁 in a string.” Or you can specify it as an escape sequence like this: “Here is the Unicode character \U0001f601 character in a string.”
The rules are pretty simple. If the code point for the Unicode character has 4 or less hexadecimal digits, you specify it as \uxxxx where each x is a hexadecimal digit and you must add leading zeroes if necessary. If the code point has 5 or 6 hexadecimal digits, you specify it as \U00xxxxxx where, again, the each x is a hexadecimal digit and you must add leading zeroes.
Take a look at Lee’s post for more details and further examples.
Saurabh Kukade is planning a series on configuring Emacs. His introductory post discusses why he thinks Emacs is so cool. Most bloggers who write about Emacs end up posting something like that, of course, but I always enjoy reading why others find the Emacs experience a good fit for them.
Kukade starts off by observing that Emacs was first released in 1976 so it’s 43 years old. Even if you limit yourself to GNU Emacs, it’s been around 34 years. Some folks describe that disparagingly as meaning that Emacs is old and used only by gray beards. It’s not true, of course, that only gray beards use Emacs but I think the characterization is wrong in a more fundamental way: Emacs has undergone 43 years of steady improvement and refinement making it a finely honed tool that outperforms its competitors.
The next thing Kukade calls out is Emacs’ use of Lisp. That has two big advantages. First, it means that any user who bothers to learn Elisp can get at the core editing routines and change them on-the-fly to suit themselves. This is partly what I mean when I say that Emacs is a sort of light-weight Lisp Machine. Secondly, Kukade says, Lisp is the ideal language for implementing text editing. Its primitives make handling text much easier than in most other languages.
The use of Lisp is, in large part, what makes Emacs so configurable. Not only can users modify the built-in functions, they can write their own functions to do special tasks. In Emacs, this has lead to the incredibly rich package system with hundreds of user-written packages that either improve on a core functionality or provide a completely new one.
Finally, of course, there is Org mode. As Kukade points out, many people have learned and adopted Emacs just to get access to Org mode. Many of those people later say, “I came for Org-mode but stayed for the incredible editing experience.”
Emacs is a big and complex system and all of us have taken the time and trouble to learn it for our own reasons. I always enjoy hearing why other people put in that effort.
It used to be, and probably still is, a rite of passage for young hackers to learn how to pick locks. I believe this started at MIT where the idea of locked /anything/—software, doors, …—was an anathema, and challenge, to the hackers there who could not let such things stand. This resulted in the infamous MIT Guide to Lock Picking.
You may think that it requires a lot of skill and practice but actually picking a modern pin tumbler lock is pretty easy. Is there such a thing as an unpickable lock? Almost certainly not but in the 1800s in Britain, two inventors, Joseph Bramah and Jeremiah Chubb each claimed to have invented an unpickable lock. These weren’t idle boasts. Bramah offered a substantial prize for anyone who could pick his lock and that prize went unclaimed for 67 years. Chubb’s lock was adopted by the British Government after substantial vetting. Both locks were defeated in 1851 by an American locksmith and inventor, Alfred C. Hobbs.
The story of these two locks is amusingly told by Arran Loomas in the video Could You Pick The Unpickable Lock? He tells the story of the locks, how they operated, and how Hobbs was finally able to pick them. For a brief span of almost 70 years, unpickable locks did exist. The video is 14 minutes, 27 seconds long.
If you like this sort of thing and are wondering what a modern day “unpickable” lock might look like, consider the Browley lock. The LockPickingLawyer has an excellent video that shows how it works and why it’s so hard to pick. That video is 17 and a quarter minutes long.
A couple of days ago, I was adding some item to my journal—which is really my engineering note book—and when my capture template prompted me for a tag and I started to type it in, I noticed that in the list of suggestions (from Ivy) there was a misspelled tag. That happens fairly regularly. Sometimes I make a flat out typo, sometimes I unconsciously capitalize a proper noun (my policy is all tags are lower case), and sometimes I use a slightly different tag from what I usually do.
When I find a bad tag, I fix it by searching my agenda files with the m option from the Agenda menu1 to bring up the headlines with the offending tag and then fix it by editing the tag with Ctrl+c Ctrl+q.
This time, I’d finally had enough and decided to get rid of them all. The question was how to get a list of all the tags? I first tried grep but the result was a mess and too hard to work with. Then I thought that if Ivy was gathering that list for its completing read, there must be an easy way to do it. I asked for help on functions, typed in “org tag”, and looked through the completions until I found org-global-tags-completion-table. That did exactly what I wanted so I fired up ielm, invoked org-global-tags-completion-table, and had a nice list of tags. I didn’t bother sorting it, I just read down the list until a found a bad tag and called the match TAGS query to bring up the affected headlines so I could fix them. It turned out there were a lot of bad tags but it was easy, if boring, to find and fix them all.
The point of this post is twofold. First, Emacs gives you the tools to fix problems in your data even if several files are involved. It also gives you an easy way to discover those tools. Secondly, the exercise reminded me of the power of ielm. Usually, when I need to run a random elisp command I do it from the minibuffer. This time I needed an easily accessible list so I used ielm. I tend to forget about it but it’s often just what you need, even in situations that don’t involve elisp development.
If I had to do this a lot, I’d write some code to handle correcting the bad tags but that didn’t seem worth the trouble in this case. Still, if I ever decide I need to, Emacs has all the tools to make it easy.
I use Ctrl+c a m but if your keybindings differ it’s the “Match a TAGS/PROP/TODO query”.
Kevin McArdle has an interesting post on working remotely. He makes an interesting point: we have all the technology to make working remotely a reality but we still talk of it as something in the future. Why, he asks, aren’t more companies remote-first?
The benefits of remote work are both obvious and documented. Companies save money—lots of money, it turns out—as do employees. Employees don’t waste time commuting or sitting in mostly useless meetings and are therefore more productive. This, of course, is hugely beneficial to employers. Perhaps the biggest win for companies is that they have a vastly larger talent pool to recruit from.
McArdle’s own company, SureSwift Capital, has 80 team members, operates in 14 time zones, and has no real offices. His experience shows it can be done and that all the advantages can be realized. His post urges other companies to realize them too.
When I first got interested in remote work it really was a dream. Hardly anyone was doing it—mostly journalists and some developers—and we didn’t have nearly the infrastructure to support it that we do now. Now the infrastructure is there and except for those famous face-to-face meeting at the water cooler, there really aren’t many cogent reasons to keep doing what we’re doing.
A year ago, I wrote about Howard Abrams’ post on Capturing Content for Emacs. I just saw a current reference to the post and reread it. It’s a really great article and worth mentioning again in case you missed it.
The basic idea is to make capturing data and inserting it into the currently clocked in task as effortless as possible. Abrams starts with some simple templates that show how to add a capture to the currently clocked in task and then moves on to adding data directly from the system clipboard to the current task. He even shows how to move selected text in an Emacs buffer to the current task.
All of that uses just the normal capture template mechanisms built into Org-mode. What I really liked was how he arranged to move data from the browser or other apps into the current task. One example is a simple shell script that you can put at the end of a pipeline to capture the output from the rest of the pipeline and import it into your current task.
He also considers capturing text and HTML preserving the necessary formatting and changing (HTML) links into Org links. He shows how to do it for macOS and Linux.
If you haven’t already read his post or you’ve forgotten the details, you really should take a look. There are a lot of great tricks that can help reduce friction in your workflow.