Python Doctests, Literate Programming, and Org Mode

If you’re a Python programmer and like to have built-in tests for your functions, you probably know about doctest, a way of embedding one or more tests in the docstring of a Python function. Normally, they don’t do anything but if doctest is loaded as the main program or one of doctest’s methods are called, the tests are run and the results are printed to stdout.

John Kitchin likes the idea but found that the nit-picky formatting of the tests was annoying so he didn’t use them very often. Of course, being Kitchin he soon fixed that and in a clever way that leverages Org mode. Rather than fuss with the formatting of the tests, he just put a noweb marker where he wanted the test to be and then included the test as a normal Org mode code block later in the file. He added in a bit of Elisp to reformat the test code so that when the file is tangled it becomes a Python script that can be invoked in the normal way to run the tests.

Kitchin thinks of this as an example of literate programming, which it is, of course, but I prefer to think of it as another example of the power of embedding code in an Org file. The function tests can be run from the Org file to get the expected results for the tests, explanatory text can be added, and when you’re finished you just tangle it to an output file. That file can be invoked as a script to run the tests or imported into another Python file to access the functions in the normal way. Very impressive. Kitchin’s post includes a short video so you can see the system in action and get a better feel for how things work.

Posted in General | Tagged , | Leave a comment

Introduction to Using Git

If you’re in the intersection of Emacs and Git users, you are almost certainly using Magit and probably don’t think about version control very much: it just works. But suppose your version control experience is restricted to CVS, SVN, or even no version control at all. If you’re like me, your first thought is probably that that’s a pretty small set but when I stop to think about it, I realize that I know lots of people stuck in CVS or even not using version control of any type.

The Lazy Dev has a nice post that will help get those folks up to speed. The post, Unleash your version control skill in 10 minutes, takes a version control neophyte from getting Git installed, setting up a repository on a remote server (GitHub is used as an example), initializing a project, and keeping things in sync regardless of where a particular change is made.

This is an elementary discussion so Emacs and Magit don’t come into it but Emacs users will have no problem jumping to Magit once they get an elementary knowledge of Git. If you’re new to Git or know someone who is, this post is worth taking a look at.

Posted in General | Tagged , | Leave a comment

Capturing Code Snippets

The other day in my post about Alain Lafon’s talk on playing Emacs like an instrument—you have watched that video, haven’t you?—I mentioned that one of the things I picked up was an Org capture template for capturing code snippets. That’s very nice and just the thing when you want to put some code in a journal or log entry.

Right after seeing the video, I saw a post from Nick Barnwell that had an even better template for capturing code snippets. His template automatically captures the language for the code block, and the file and line number from which the code is being extracted. That minimizes the amount of text that you have to enter manually.

You may have to autoload which-function if you aren’t already using something like which-function-mode. Also note that the template is assuming you’re going to be grabbing the code snippet from a file you have open in Emacs. That’s probably almost always true for a capture template of this type.

When I first started using capture templates, they were described as a way of quickly recording a note or thought while you were busy with something else and then getting back to the job at hand. That’s still true, of course, but I find that they’re just as useful for entering data related to your current task. For example, when I’m reading an article that I’m considering writing about on Irreal, I capture a link to the article and any thoughts I have about it with a template that adds the information to my blog queue. Once you start using capture templates, you keep finding new uses. Barnwell’s post is another example of that.

Posted in General | Tagged , | Leave a comment

A Tip for Org Mode N00bs

Wilfred Hughes serves up some useful advice for those just starting out with Org mode:

I’ve given this same advice before but it’s worth repeating. Org mode is a huge and complex package with many capabilities. If you try to learn everything at once, you’ll get discouraged and possibly even abandon Org.

That was certainly my experience. When I first started, I used Bernt Hansen’s excellent Org Mode – Organize Your Life In Plain Text! as a guide and tried to configure everything at once. The result was that I didn’t understand anything and mostly didn’t use Org at all. When I started over, I configured only a small subset of the capabilities and got familiar with them through repeated use. Later, I added more functionality as I found new ways to use Org in my workflow. That process is still going on even though Org mode is at the center of most things I do on my computer.

Do yourself a favor and start with just a couple of Org’s capabilities. You’ll have much better results that way.

Posted in General | Tagged , | Leave a comment

Some Dired Tips

Tim Visher, who used to produce the popular VimGolf in Emacs Videos, has a couple of useful tips about using dired:

As a clarification, note that w copies the file name not the file itself into the kill ring. You can do several files at once by marking them.

I don’t think I’ve seen any of them before and they certainly aren’t on the dired cheat sheet that comes with Emacs. You can, of course, find the ‘w’ command in the dired help buffer but as far as I can see you have to check the documentation for dired-copy-filename-as-kill to get the information on the prefixes.

Posted in General | Tagged | Leave a comment

California Stores the DNA of All Babies Born in the State

What could go wrong? The iron law of data collection, that’s what. It’s been a while since I’ve written about the iron law, so here’s a quick recap: The iron law states: Whenever the government (or anyone else for that matter) collects data, two things are guaranteed:

  1. No matter the reason given for its collection, it will be used for more and more purposes.
  2. It will inevitably be abused.

Through the years, I’ve provided several examples of the iron law in action. California’s collection and retention of babies’ DNA is only the latest and it exactly parallels what happened in Sweden1: the DNA was collected with the rationale that it was needed for the testing and treatment of genetic diseases. It wasn’t long before law enforcement started showing up with warrants. In California’s case, the state can even sell the data to third parties for “valid scientific studies.”

Although California mothers are supposed to be told that they can request that the data be destroyed, they often aren’t and even when they are it’s with a mass of other new born baby information that all but guarantees it won’t be read. Efforts to have parental consent be opt in was beaten back by vested interests. You can read the article for the details.

The point, though, is what it always is: if you allow the data to be collected it will eventually be abused. The only way to prevent that abuse is stop the collection or in the case of such things as testing for genetic diseases that the samples be destroyed as soon as the analysis is completed.

Footnotes:

1

Ironically, in that post I said that such collection would be blatantly illegal in the U.S. That shows what I know.

Posted in General | Tagged | Leave a comment

Emacs Tools for Writers

As you all know, I’m fond of posts that show the versatility of Emacs by documenting its use by writers. At first glance, writing—a novel, say—seems to be the direct antithesis of what most of us use Emacs for. But when you think of it, it’s all just wrangling text and we all want to do that in the most efficient way possible. That’s were Emacs comes in.

Scott Nesbitt has a nice post entitled 5 Emacs modes for writers. Those five modes are:

  1. Muse,
  2. Org mode,
  3. Flyspell,
  4. WC mode, and
  5. WriteGood mode.

I depend on three of the five. I use Org mode for virtually all of my writing these days so I don’t need Muse. Applications like WriteGood mode remind me of my eighth grade English teacher so I avoid them for admittedly emotional reasons. I use a different app for word counting—also called WC mode—but either one will serve. Any or all of these tools will make whatever writing you do easier.

Nesbitt also mentions Fountain mode (if you’re doing screen manuscripts), Markdown mode (if you prefer Markdown or have to use it in some instances), and Writeroom mode (if you want to write on a blank screen). Years ago, Jerry Pournelle used to sing the praises of an editor called (I think) WRITE. It was for CP/M and would doubtless be considered primitive today but it had the virtue of being distraction-free by offering a blank screen with no tool bars or other widgets to seduce your attention. If that sounds attractive, give Writeroom a try.

Posted in General | Tagged , | Leave a comment

Making Slides with Org-reveal

Scott Nesbitt has an informative post on how to set up and use Reveal.js and Org-reveal for generating slide decks. There are several solutions for making slides that leverage Emacs and Org mode but Org-reveal is the simplest that I’ve seen. If you’re giving talks all the time, you should at least look at Beamer and it’s org interface but if you only occasionally need to generate slides and you’re looking for a simple, quick-start method, Org-reveal is just what you need.

Nesbitt’s post tells you how to install Reveal.js and Org-reveal. Note, though, that if you’re using ELPA, the name of the package is “ox-reveal” not “org-reveal.”

Once you’ve gotten Reveal.js and Org-reveal loaded, making a slide deck is simply at matter of writing an Org outline, where each headline corresponds to a slide. You can make subsidiary slides by using sub-headlines as described in the Org-reveal README on GitHub.

Nesbitt’s post shows you how to control the look of the slides and choose the transition technique. He also shows you how to include images. Check out the README for more detailed information such as how to include Mathematics, give slides headers, footers, and numbers, and a few other “advanced” techniques.

If you’re giving that talk tomorrow and don’t have time to waste, Nesbitt’s post will tell you all you need to know. If you have a bit more time, the README file in the Org-reveal repository will show you how to spruce the slides up.

Posted in General | Tagged , | Leave a comment

Batch Editing with ed

I’ve written before about the ed editor and the faithful who still use it today. A tweet by Mike Zamansky lead me to this Julia Evans post on batch editing files with ed. Evans has a typical editing problem: she wants to duplicate each line in several files that contain a certain string but also change the string to something else on the new line. See her post for the details.

She chose to do this by writing an ed script to make the change and then call ed with the script (presumably) as part of a larger shell script that does this for each file. My first thought was that this made sense even today because ed scripts have always been used in just this way and it’s still an easy and elegant solution. But then I got to wondering how I’d perform that task.

My inclination was to try some sort of Emacs trick, of course. Evans is a Vim user so she doesn’t have the awesome power of Emacs at her fingertips and can be forgiven for falling back to ed. Since we haven’t had an Emacs puzzle for a while, here’s a challenge: figure out how you’d use Emacs to get this done.

Zamansky, being less inclined to rush in, offers the following excellent Sed solution:

It’s probably hard to beat that solution even with Emacs but see what you can do.

Posted in General | Tagged , | Leave a comment

Spaces After Periods

I feel almost like a troll writing about this. The controversy as to whether there should be one space or two after a period is surely one of the most pointless of holy wars. Yet holy war it is. For those of you can came in late—that is, who grew up using computers instead of typewriters—the issue is whether typists should put one or two spaces after the period ending a sentence. The two spaces made sense for typewriters with their fixed-width fonts as it made the text slightly easier to read. When computers came along and everyone started using proportional fonts, the second space was no longer needed. At least that’s what the typography experts said.

Nonetheless, the debate raged on. Having learned to type on actual typewriters, I was for many years in the two space camp, if only out of habit. Around 2011, I changed to using a single space, adjusted my Emacs to recognize that as a sentence end (as related here), and have been happily conserving spaces ever since.

One of the reasons I say the argument is mostly pointless is that when documents are typeset, the composition software is probably going to ignore that extra space anyway. That’s something Avi Selk found out when he tried to insert an extra space in the headline to this Washington Post article on the controversy: it broke the formatting. And, sorry two-spacers, once he got it working it looked weird. Follow the link and see for yourself.

Both Selk’s article and a a similar one in Ars Technica by Sean Gallagher report the results of a study published in Attention, Perception, & Psychophysics that found two spaces slightly increased reading speed in some subjects.

Leaving aside the fact that the majority of psychological studies are not reproducible and therefore suspect, there’s plenty to criticize about this study on its own terms. Most glaringly, to me, is that the study tested its subjects using the fixed-width font Courier New 14. The researchers justified this on the grounds that the font was standard for this type of study but that misses the point: Of course the extra space helps with typewriter-like fonts. Everyone agrees about that; the question is does it make sense with proportional fonts. In any event, the modest increase in reading speed (≈ 10 words/minute) was seen only by those who used two spaces.

So the TL;DR is that we don’t really know more than we did before and the debate will continue unabated. The Washington Post article appears to favor the two-spacer camp while the Ars Technical article seems partial to the one-spacers. Go read both articles; there’s something for everyone.

Posted in General | Tagged , | Leave a comment