Nick Higham’s Blogging Workflow

Nick Higham is a working mathematician so his blog has a heavy mathematical content and that means that he’s very concerned with integrating LaTeX into his workflow. Fortunately, that’s pretty easy because he writes his posts in org-mode and publishes them on a WordPress blog. That means he can embed the LaTeX in an Org file and when it get exported, it gets turned into the proper mathematical representation.

Higham has a short post on his blogging workflow. He uses org2blog as I used to do before the XML-RPC protocol stopped working with my hosting provider. Org2blog makes it really easy to write posts in Org and export them to WordPress in a single operation but he sometimes still needs to adjust the HTML to get the final result he wants.

His post is mainly useful for those who have a lot of mathematical content but anyone thinking of starting a blog could profitably take a look.

Posted in General | Tagged , | Leave a comment

Being More Productive with Emacs

Peter Prevos has an excellent series of beginner articles on being more productive with Emacs. The series comprises the following posts:

  1. Getting Started with Emacs
  2. Configure Emacs
  3. Distraction-Free Writing with Emacs
  4. Getting Things Done with Emacs
  5. Taking Notes with Emacs
  6. Create Websites with Emacs
  7. Writing Articles and Books with Org Mode
  8. Manage your literature with Emacs BibTeX Mode
  9. Manage files with Emacs
  10. Viewing Images with Emacs
  11. Read RSS feeds with Emacs and Elfeed
  12. Configure EMMS
  13. Using Emacs on a Chromebook
  14. Export WordPress to Hugo Markdown or Org Mode with R

There’s also a link to the configuration files discussed in the posts.

If you’ve got a bit of experience with Emacs, you probably won’t learn a lot from these posts but if you’re a beginner or know someone who is this series may be just the thing to get you started.

Posted in General | Tagged | Leave a comment

Getting a List of Open PRs from Github

Geoffrey Lessel is an Elisp n00b. Really a n00b. He’s not sure what the car and cdr of a list are and he doesn’t understand backquotes. But he’s not afraid to dig in and discover things as he goes along. He proves that by taking on a project that many would consider too difficult for a beginner: he wants to retrieve a list of open pull requests from Github so that he can select one and display it in his browser.

There are a lot of moving parts in that exercise. For example, you’ve got to connect to Github, deal with authentication, parse the returned JSON, extract the relevant information as a list, pass the list to a chooser function, and call your browser of choice with the URL for the chosen PR. All that might be a challenge for even an intermediate Elisper but Lessel shows how to approach the problem even if you’re not sure where you’re going at every step.

He does that by leveraging Emacs’ discoverability and exploratory programming. First he writes some code just to retrieve a bit of JSON from a site that doesn’t require authentication. He experiments with ways of parsing the JSON into a more convenient form and then extracting one of the values. Next he uses some of the auth-* functions to login into Github and retrieve the data he needs. Finally, he extracts a list of the PRs from the JSON that Github returned. He leaves the building of the choice list and calling of the browser to his next video.

This is a long video—almost an hour and 23 minutes—and a lot of time is spent just figuring things out. More experienced Elispers might get exasperated as he feels his way along but everyone can learn a lot from how he does figure those things out. You might even learn something new. For example, I learned about seq-doseq, a very useful generalization of dolist to arbitrary sequences. The next time you hear someone whine that Elisp is too hard to learn and use, point them to this video.

Posted in General | Tagged , | Leave a comment

Correcting Text Messages

A few years ago I used to joke that I was getting in touch with my inner teenager when I texted with SMS. These days, I text more often than I send email and Apple’s iMessage makes it easy to text from any of my devices.

One way that email is superior to texting is that it’s easier to send messages without typos or mistakes. My texts often have mistakes. About half the time that’s because autocorrection thought it knew what I meant better than I did. The other times it’s because it’s harder to type accurately on an iPhone or even an iPad.

Whatever the cause of the errors, I’ve often wished that I could edit a text after it was sent. People have evolved a number of ways of dealing with this. One popular method sends the corrected word with a * prepended. That’s too ambiguous for me so I use the ed substitution notation s/xxx/yyy/. That’s pretty much a standard notation in the programming world—Sed, Vim, and Perl all use it—so it’s well understood by all my technical interlocutors but, oddly, even my non-technical friends and relatives have no problem understanding it.

Wil Shipley has an interesting idea: build a text correction protocol on top of the ed/Perl/Sed commands. His idea is that email clients supporting the protocol would allow the sender to edit the erroneous text, which would, in turn, send the appropriate Sed command to the receiver’s client. The receiver’s client would redisplay the text in its corrected form along with an indication that it’s been corrected. The old, erroneous, text would be viewable by clicking on the corrected indicator.

The beauty of this solution is that it has a soft fallback for nonconformant email clients. On the receiver’s end it would simply keep displaying the original message followed by the Sed command. In other words, just what I and many others are doing now. If the sender doesn’t have a conformant client, they can simply send the Sed command manually—again, what many us are already doing—and the user of a conformant receiver will see it displayed as a corrected message.

This is a great idea and should be fairly easy to implement without unduly impacting current clients. I hope one of the big players picks it up and runs with it. As Shipley says, once one vendor implements it, the others will follow.

Posted in General | Tagged | Leave a comment

Whence COVID-19

Public health officials have seriously damaged their credibility with COVID-19 messaging. Many of the things they’ve told us have turned out not to be true. Some, such as their early advice on mask wearing, was a transparent lie that didn’t make sense even on its own terms. If you lie to me once, why should I believe anything else you tell me?

Now that we have a vaccine and the end of the epidemic seems in sight, it seems like a good time to ask where the virus came from. The received wisdom is that it came from bats via the Wuhan wet market. According to this theory, the virus made the jump from bats to an intermediate species, and then to humans. That’s how the SARS1 and MERS viruses did it. This theory is the one championed by the virologist community and some other public officials. And who should know better? Unfortunately, there are several problems with this theory.

The other major contending theory is that the virus escaped from the Wuhan Institute of Virology that was doing gain of function experiments on coronaviruses. That theory was immediately and emphatically disparaged by the virology community, most public heath authorities, and the press even though such leaks are frighteningly common. No evidence was adduced to justify this dismissal. Instead, they authorities simply said it was ridiculous and a conspiracy theory.

If you have a scientific or even a skeptical bent, these denials should be raising a red flag. They don’t sound scientific, they sound political. Irreal doesn’t take any position on the matter because, like most of you, I don’t have the domain knowledge to make an informed decision. Fortunately, Nicholas Wade has a careful and exhaustive article that considers the evidence. The TL;DR is that there’s no definitive evidence either way but that what there is argues heavily for a leak from Wuhan labs.

Wade’s articles seems to me an honest recitation of the facts. It doesn’t reach a firm conclusion but provides sufficient evidence for you to draw your own.

Posted in General | Tagged | Leave a comment

Red Meat Friday: Y2K Redux

It’s been a while but many of us still remember the problems, hype, and really bad movie centered around the Y2K bug. For you kids, that was a problem caused by the common practice of storing the year of dates as YY instead of YYYY. It saved a couple bytes (or characters) per date and not that long ago storage was hideously expensive so it seemed like a good tradeoff. Until the year 2000 loomed bringing the threat of financial system shutdown due to failing software.

In the end, it turned out to be pretty much a nonevent due, in part, to heroic efforts to get all that software fixed before the new millennium. Everyone gave a huge sigh of relief and software engineers promised themselves that they’d never make that mistake again. Except.

To be fair, this problem was a little less predictable than Y2K but notice that once again there was a lack of concern until disaster was imminent. Maybe we didn’t learn the Y2K lesson as well as we thought.

Posted in General | Tagged | Leave a comment

Git With Solo Projects

Over at Fosslife, V.M. Brasseur considers the question of why you should use Git, or some other version control system, for your solo projects. Brasseur was shocked when one of her coworkers expressed surprise that she used Git even for personal, one-developer projects. I do the same thing. I check virtually all my work into Git and have for many years.

But why would you do that? Brasseur gives seven reasons to use Git on solo projects. The TL;DR of her reasons are:

  1. Syncing between computers so you can work on the project from any of your computers.
  2. Backup (especially with an offsite repository).
  3. Being able to backtrack to previous versions for debugging.
  4. Organizing your data by putting it in known places.
  5. Code reuse.
  6. Issue tracking.
  7. No project is really solo. Future-you will appreciate the project history.

Those are all good reasons but the real question is: why wouldn’t you version control your work? It doesn’t really cost anything other than a little extra, increasingly cheap disk space, and can really save the day when you need to dig into the project’s history.

Posted in General | Tagged , | Leave a comment

Fish Sticks

I just saw an article that incited in me an atavistic fear and loathing. What was it that left me trembling and whimpering? Fish sticks. The very name brings back childhood horrors. Long ago, in the dark ages before the Internet, I was in (what we now call) middle school. On most Fridays—in deference to Catholics who weren’t allowed meat on Fridays—we were served the abomination called fish sticks. They actually made me gag but the teachers insisted we eat them.

It never occurred to me that anyone actually liked them. I always considered them just another way for the school system to torture their students. But the article says that fish sticks are beloved by many and tolerated by many more. I would have been surprised to find anyone who would admit to even tolerating them. Some people say, apparently, that you can almost pretend they aren’t fish. If only that were true. For the record, I like seafood but fish sticks don’t qualify.

It turns out that fish sticks were invented to solve a problem. Stronger motors and bigger boats back in the 50s meant that there were too much fish being caught to sell quickly so they started skinning, deboning, and freezing it on the boats. That raised the question of how to sell the frozen fish. After a series of failed experiments, they settled on fish sticks, which did surprising well. The article has other curious facts about fish sticks. If, like me, you have a complicated history with them, you might enjoy the article. As for me, I’m just glad that I don’t have to choose between starving and letting a single crumb of fish stick pass my lips.

Posted in General | Tagged | Leave a comment

Using Org-capture With Org-drill

I saw a pointer to this New York Emacs Meetup talk from 2016. It’s about how Josh Moller-Mara uses org-drill and org-capture together to learn Chinese. Most of us don’t need to learn Chinese, of course, but we all do have things we need to learn and org-drill’s implementation of spaced repetition is an excellent way to do it.

The most interesting part of the talk to me was how Moller-Mara uses org-capture to easily build the flash cards. These are more complicated than usual because Moller-Mara includes additional information such as a code that describes what the Chinese character looks like. What’s nice is that the process is almost entirely automated. When Moller-Mara comes across a new character, he cuts and pastes it into an Org-capture template and the template looks up all the information and adds it to the flash card. All this is driven by the text file Chinese/English dictionary CEDICT. When Moller-Mara pastes a Chinese character into the template, the template code simply does a regex search of the CEDICT file to find the definition.

This is a really good example of how flexible org-capture is and how it can do non-trivial processing of its input. That’s because you can put calls to arbitrary Elisp in the template definition. It would be easy to adopt Moller-Mara’s ideas to other, similar applications.

The slide deck for the talk is here. At the end, are links to his templates and software. The talk itself is just a bit over 36 minutes so plan accordingly.

Posted in General | Tagged , | Leave a comment

Paper on Native Compilation

If you’ve been following the Emacs native compilation effort and are curious about the technical details, Andrea Corallo, Luca Nassi, and Nicola Mancahave have an arXiv paper that describes Bringing GNU Emacs to Native Code. The paper does a good job explaining the technical details of how the native compiler works without requiring specialized compiler theory knowledge.

The TL;DR is that the native compiler uses the intermediate language from normal Emacs byte compilation as input and produces GCC intermediate code (IR). The final step is for GCC to compile this IR into native machine code. It’s a nice solution because it lets GCC worry about generating the final code so the solution should work for any architecture that GCC targets.

The details are a little more complicated, of course. The Emacs byte code IR is first translated into a special IR (called LIMPLE) that the native compiler can operate on and make optimizations that GCC can’t for various reasons having to do with the differences between LISP and C. It’s LIMPLE that is actually translated into the GCC IR. The paper explains all this so you should definitely read it if you’re interested.

Posted in General | Tagged | Leave a comment