Nicolas Petton writes that the first pretest for Emacs 27.1, Emacs 27.0.90, is available for download and testing. If you don’t mind living a bit on the edge and would like to try out the latest and greatest, give it a try. You’ll be helping the developers by testing the new software and moving us toward the final release of Emacs 27.1.
As always, thanks to Nico, Eli, John and everyone else involved for their hard work in moving Emacs forward.
I’ve often written that reproducible research is the best way to do science. Over at Molecular Brain, it’s editor, Tsuyoshi Miyakawa, has a long and interesting editorial that argues that if you aren’t providing raw data, you aren’t doing science. In other words, reproducible research isn’t the best way of doing science, it’s the only way.
The editorial, No raw data, no science: another possible source of the reproducibility crisis, relates some startling facts. For example, in cancer research the reproducible rate, according to one study is only 20–25% and according to another it is only 11%. In cancer research. This is serious research with life altering consequences but more than 75% of the time the results can’t be verified.
It gets worse. Miyakawa’s policy is that if the results appear “too beautiful to be true” he will asks the authors for raw data before sending the paper out for review. That’s an excellent policy but what happens next is also startling. Since 2017, Miyakawa has asked for raw data 41 times. In 21 cases the papers were withdrawn without providing the data. Of the other 20 cases, only one paper was accepted. Miyakawa rejected the others for providing insufficient data.
Even if you haven’t achieved Irreal levels of cynicism, it’s hard to avoid concluding that in some of these cases fraud is involved. Miyakawa concludes the same. Journals could make significant inroads into this problem if, like Molecular Brain, they insisted that researchers provide their data. Organizations providing research grants could do their part by insisting that the raw data gathered by the research they fund be made available. What’s happening now is absurd.
If you’ve ever wanted to play around with the patriarch of the Emacs family, now you can. The TECO editor was developed in 1962 to work with paper tapes. In fact, TECO originally stood for “Tape Editor and Corrector” but the acronym’s meaning was changed to “Text Editor and Corrector” as it was adapted for other media. The other salient fact about TECO is that the original Emacs—the literal Editing MACroS—was implemented as TECO macros.
Every once in a while I see someone proudly announce that they still use, or at least prefer, TECO but until Mike Zamansky’s Emacs vs. Vi rant I had never seen it in action. I assumed that those still using it were one of the people who collect old computers such as the PDP-1 on which it was originally implemented. It turns out, though, that it was ported to C and is available in a GitHub repository maintained by Blake McBride.
Of course, if you think line editors such as ed are a pain, you should know that TECO is a character editor—presumably from its heritage as a paper tape editor. The README for the repository and the manual have more details on how it works. If you feel like having a retro moment, now you know where to get it.
One of the most powerful and useful functions provided by Org Mode is the capture facility. With it, you can easily capture data and context and store it in an Org file of like items in any of a number of useful formats. I have capture templates for everything. If I see a blog post or tweet that I think might form the basis of an Irreal post, I can pop up a capture buffer that will automatically capture the context—the Web page or tweet embedding code—along with any notes that I want to add. These go right into my Blog Ideas org file for later use. Similarly, I never write directly in my journal. I just pop up a capture buffer, write whatever I have to say, and it gets filed with the proper date and time in my journal. I have a template for every type of data that I enter regularly. It’s a huge timesaver.
If you look at a capture template, it can seem intimidating. There are all sorts of special symbols and keywords with no obvious meaning. In truth, it’s not really very complicated once you learn how things work and you don’t have to remember the keywords and symbols except when you’re writing the template.
If you’re a visual learner, you might be interested in Protesilaos Stavrou’s video on how to write and use capture templates. He says at the beginning that the video isn’t meant to be comprehensive but he covers just about everything you need to know and points you to the appropriate help system documentation for keywords and symbols that you can use. If you aren’t already using Org capture you’re working too hard and should take a look at Stavrou’s video.
The video is just short of 29 minutes so you’ll need to schedule some time. Even if you’re already using Org capture you might learn a few new things so it’s worth taking a look if you can find the time.
Ars Technica has an interesting article about the on-going open access wars. University libraries, like everyone else, have to operate on a budget and fee increases from journal publishers is putting the squeeze on those budgets. Librarians are starting to fight back. I’ve already written about the University of California’s refusal to renew its contract with Elsevier and Ars Technica’s article documents another data point in the struggle.
Florida State University’s library has also refused to renew their Elsevier contract and despite dire predictions from the publisher about even costlier per view charges, FSU does not appear to be suffering. Elsevier told them they could expect a one million dollar increase in costs but to everyone’s surprise, the library has spent only $20,000 in the eight months after their cancellation.
The article makes clear the UC and FSU are still in the minority but that pressure is increasing on the publishers and the revolt is gathering steam. As the article points out, you can understand why the publishers are loathe to give up their business models. They get their content for free, use volunteers to referee and edit it, and sell it back to the institutions that financed the research for a premium price.
Elsevier has a new CEO who has shown a willingness to be more flexible. Perhaps open access will move from a dream to a reality sooner than we hoped. Already, Ars Technica says, 31% of journal articles published in 2019 are not behind a pay wall.
After my recent disaster with my old MacBook Pro, one of the functionalities that I still haven’t restored is the ability to call Org capture from outside Emacs. I used to have a bit of Apple Script that I could call to do that but it was sometimes flaky so I was inspired to find something better with my new setup. This is especially important to my workflow because I use it all the time to capture links to Web pages and store them into my blog queue.
The most promising approach seemed to be using org-protocol. I found two excellent, recent blog posts that describe using org-protocol for capturing from other apps. Just what I wanted. The first, by mistan, described how to set things up in Linux. The other, by Christian Tietze, discussed the same thing under MacOS.
Using Tietze’s post as a guide, I configured org-protocol and tried calling org-capture from the terminal. I called my TODO template, like Tietze did, and it worked perfectly but I couldn’t figure out how to get the Org Capture menu, which my workflow needs as there are multiple templates that I need to call and I didn’t want to use different calls for each one.
Then I remembered writing about the methods used by Karlicoss to capture data from many different sorts of applications. The crux of his method is a script that does most of the heavy lifting and then a series of other scripts that call that one. I shamelessly stole his script, made some changes for MacOS, and called it from a script named call-org-capture. That worked perfectly. I can bind the call to call-org-capture to a convenient hot key and the problem is solved.
If you’re looking for a general way of calling Org Capture from other applications, I can recommend this approach. It’s working very well for me.
During FOSDEM ’20 Tom Tromey gave a very interesting talk on what he believes the future of Emacs will be. Others, such as Perry Metzger, have also addressed this question. Almost always, one of the suggestions that come out of these talks is the idea of rewriting Emacs in some other language. Sometimes, as with Metzger’s talk, the idea is to replace the C code with some other, safer language such as Rust. Other times the idea is to replace Emacs Lisp with something else such as Guile, Common Lisp, or even—shudder—JavaScript.
Tromey’s idea seems radical but is actually the conservative approach. His idea is to replace the C core of Emacs with … Elisp. Everyone loves to hate on Elisp but Tromey likes it and believes that it’s just the right solution for Emacs. I’ll let you listen to his talk to hear his justification for that but he makes a convincing argument that doing so will solve a lot of problems. For example, implementing threads is tremendously difficult because of race conditions hidden in the C code. If everything were written in Elisp and compiled with a compiler that understood threading, this could be handled more or less trivially.
Tromey’s idea is that while there would be no C code in the core it would still exist in libraries that do things like display PNGs. All that would be handled through a foreign function interface and be isolated from the core functionality. The idea is not to just move the current C code into a library.
The talk is 19 minutes so it shouldn’t be too hard to fit it in. One problem I had was, I guess, limited bandwidth from the server. The talk kept stopping for a second or two giving it a stuttering effect. Perhaps everyone else was trying to listen at the same time I was so you might do better but be warned.
As regular Irreal readers know to their sorrow, one of my favorite hobby horses is the need to keep control of your data. Broadly that means keeping it in open formats and on computers that you manage. If you’re committing your only copy of valuable data to some cloud service, you’re acting recklessly and are likely to suffer the consequences.
Jack Wharton has an interesting post in which he discusses the need and means of migrating his data off Google. More precisely, he wants to create a backup for his Google data while still using Google services. Wharton is a Google employee who “trust[s] Google completely in their ability to correctly retain [his] data” but he worries about Google’s recent inclination to lock users’ accounts for suspected Bad Think™.
I see many articles discussing getting Google-free but Wharton’s explains in detail how to get your data from Google. It is, he says, the least you should do. The processes turn out to be manual and a bit finicky but doable. Wharton has two decades worth of email, photos, and other important papers stored with Google so he needs a lot of backup space. He solved that problem by building a storage server to hold it all. Again, he gives a fair amount of detail on this so if you have similar storage needs you should definitely take a look at his solution.
If your requirements are more modest or you’re operating on a limited budget, you can still buy an inexpensive, reasonably-sized portable hard drive for your backups. After that, all that’s required is a regular backup routine to make sure you always have up-to-date copies of your data under your direct control. I store various data on iCloud so that it’s available across all my devices even when I’m on the go but none of it is committed only to iCloud. I always have a local copy. If you follow a similar policy, it won’t matter (much) if some cloud provider goes away or decides not to do business with you anymore.
Over at Opensource.com, Seth Kenlon has an article that asks the question, “Who cares about Emacs?” After all, the editor is ancient. Its GNU incarnation has been around since 1983 and there are plenty of glittery new editors to choose from. Furthermore, whatever functionalities you like in Emacs are probably available in those other editors too. Kenlon asks if Emacs is even relevant anymore.
Of course, we all know the answer. Kenlon gives several reasons why learning and using Emacs still makes a lot of sense. You can read the article for the complete list but the two that resonated with me were that Emacs works just fine in text mode and, most importantly, that it’s hackable.
Some folks prefer using Emacs in a terminal—and emacsclient makes that simple and painless—but even those of us who prefer the GUI there are times when the GUI version is too heavyweight. In those cases, having a text based Emacs with all the features of the GUI version—modulo things like displaying PDFs or images—is a real win.
Of course, the thing that sets Emacs apart is its hackability. Lots of editors claim they’re hackable but often this means, “We provide an API and maybe a scripting language to use with it.” Emacs is not like that. At its base, Emacs is a Lisp interpreter and almost all its functionality is implemented in that Lisp. The important point is that that Lisp is available to the user too, so you can change or add functionality on the same basis as the original implementers. There’s no API to limit what you can do; you can do anything.
Hardcore Emacsers won’t learn anything they didn’t already know but the article is an enjoyable read and worth a few minutes of your time.
Emacs has many subsystems that are complicated enough that they have their own reference cards: Dired, Org Mode, and Calc are prime examples but there are others. If I find myself using a refcard frequently, I bookmark in my browser and maybe in Emacs’ bookmarks so it’s easy to find. I recently saw a tweet with another idea:
One related tip for #Emacs folks: Tons of refcards are already on your machine. Locate them with:
M-x locate <RET> refcard <RET>I use the Dired refcard very often. https://t.co/9q8LVAN1cu pic.twitter.com/0YX1oXw74h
— Vedang Manerikar (@vedang) February 21, 2020
That never occurred to me probably because the locate database isn’t built by default on MacOS and I’ve never bothered to build it. The Mac does have Spotlight, though, which includes locate’s functionality so I invoked it and typed in “refcards.” Just as Manerikar said, I got a list of every refcard on my system. When I clicked on dired-ref.pdf it opened a Preview window with Dired’s refcard. That’s really handy. I may even build the locate database just to try it out there.