Irreal

Mike Zamansky is getting ready to give a presentation at a professional conference. As always, this means preparing a slide deck and Zamansky is faced with deciding how to do it.

In the past, he’s described reveal.js as his go to presentation software but he decided to look at the other options. In particular, he looked at ox-beamer and epresent as well as ox-reveal. His latest video discusses each of these and what he chose to use for his presentation.

All these solutions share the virtue that you can write your slides with Org mode and export them to ready-to-show slide decks. He starts by explaining why he doesn’t just use something like PowerPoint, Google Slides, or one of their free software siblings. Those systems, he says, force him to focus on how the slides are laid out and that gets in the way of writing coherent content. He much prefers to write in Org mode taking advantage of its editing capabilities and leave it to the exporter to make the final results look pretty.

His first attempt was to use beamer. Although he likes the way the slides look, he found beamer difficult to use. He doesn’t give very many presentations so it would be hard to remember the details of using it even if he made the initial investment in learning the system.

Epresent’s slides don’t look as nice as those from the other two systems but they have the virtue of displaying from within Emacs. It’s also very easy to navigate through the slides.

Finally, Zamansky considers reveal.js and its Emacs interface, ox-reveal. It combines a nice looking final product with a dead simple input structure. Basically, any Org file can be exported as a slide deck by the inclusion of a single statement telling ox-reveal where reveal.js is located. In the video, Zamansky just uses the epresent source file for the reveal.js example. All he needed to do was point it towards reveal.js. He also showed how it’s possible to serve the slide deck directly from GitHub. That could be handy if it’s not possible to use your own laptop for some reason or another.

The video is a bit longer than usual (20:12) so you may need to schedule some time. As always, it’s definitely worth your while to watch it.

Gregory Stein has an excellent post on Literate Programming with Org-Mode. Despite the title, it’s really more about leveraging Org Babel to create literate documents that contain notes, code, and results. This is, of course, the same area that Howard Abrams covered so well with his Literate DevOps post and video and Stein mentions Abrams work but also adds some material that I wasn’t familiar with.

In his section on working with code blocks, Stein covers how to set parameters that are specific to a language. That’s not useful for individual code blocks, of course, but it’s handy for file-global settings in, say, the :PROPERTIES: drawer when the file contains code from more than one language. He also shows how to enable the asynchronous execution of the code blocks using the ob-async package.

Finally, Stein offers an extended example of setting up a Python virtual buffer, If you program in Python with Emacs, that alone makes his post worthwhile.

Stein’s examples are a little less complex than Abrams’ so his post is a nice introduction to the subject and should probably be read first if you haven’t already read Abrams’ post and watched his video. This is really useful material that’s sure to give you plenty of good ideas; I recommend reading both Stein’s and Abrams’ posts and, of course, watching the video.

Howard Abrams has a very nice post in which he talks about how he uses Org capture in his workflow. Most of us are familiar with Org capture and the use of templates to store data in some Org file. I use them all the time and they are a critical part of my workflow.

Abrams’ post is about how he sands down the friction points involved in the process to make capturing data as painless as possible. His main trick is to use the currently clocked task as the destination for his captures. One of the things that adds friction to the capturing process, he says, is the need to determine where the captured data should go. It turns out that you can make the currently clocked task the destination so that the data will automatically go to the Org file (and headline) you’re currently working with.

With that idea in mind he created a template to move the highlighted item to his target Org file. That’s pretty nice but there’s still the distraction of creating and seeing the Org capture buffer. He solves that by creating a couple of templates that just store the selected data without bothering with a capture buffer.

Next, he considers capturing code and the metadata (such as file name and location) that goes with it. This requires a bit of Elisp but is pretty simple and easy to understand.

Finally, he thinks about capturing data that is not in an Emacs buffer. He wrote a shell script that you can pipe data into and have it capture the data and store it in the currently clocked task. That’s very handy when you want to capture the data from some external task or pipeline. He also wrote some scripts (particular to macOS) to scrape data and its formatting from a browser page.

Abrams post has a lot of useful ideas and is worth taking a look at. You may find some or all of them useful in your own workflow