Chris Wellons on Emacs and RSA

Chris Wellons likes to make Emacs do unexpected things (see 1, 2, and 3 for instance). His latest example is an implementation of the RSA public key algorithm in Emacs Calc.

It’s only a toy implementation, of course, but the wonder is that you can do it at all in an editor. Of course if your editor is named something besides Emacs, you can’t but, as I’ve said many times before, Emacs is more of a Lisp environment with a library optimized for text editing. That still wouldn’t be enough because Emacs Lisp doesn’t have a full numeric tower. In particular, it doesn’t implement large integers.

Fortunately, Elisp is powerful enough to support the Calc library, which does support large integers. I’ve written about the wonders of Calc before and use it pretty much every day. What Wellons demonstrates is how to use the Calc functionality programmatically. You probably won’t have a need for an Emacs implementation of RSA but if you want to make use of the Calc functionality in your own Elisp code, Wellons’ post has a lot to teach you.

Posted in General | Tagged , | Leave a comment

Moving Through Edits

Ben Maughan over at Pragmatic Emacs points to a useful package that lets you move back and forwards through editing changes. It’s implemented in the Goto Chg package. The easiest way of thinking about it is that it behaves like undo/redo without actually making any changes. It merely goes to the place where the change would be made.

That may not seem to useful at first blush but, in fact, I often find myself wanting to do just that. Sometimes it’s just that the buffer is dirty but I don’t remember making a change and this package makes it easy to see what that last change is. Of course, undo followed by redo does the same thing but it doesn’t allow you to easily scroll back and forth among all the changes.

The goto-chg package is available on Melpa and Marmalade.

Posted in General | Tagged | Leave a comment

John Wiegley on Haskell

Almost every serious Emacser knows by now that John Wiegley has taken over as the Emacs maintainer. Everyone appears united in their belief that this is a good thing and that Wiegley will be a great maintainer.

As you’d expect, Wiegley is an Emacs Lisp export (see this video with Sacha on Elisp development, for example). What you might not be aware of is that Wiegley works primarily in Haskell. There’s a wonderful video of Wiegley discussing the benefits of Haskell and his experience with it. He says that the big strength of Haskell is that it’s hard to write incorrect code that compiles. If you can get the compiler to accept your code then it will likely work as intended.

Haskell isn’t a silver bullet, of course, but according to Wiegley, it does make it easier to write good code. The video is 26 and a half minutes long but worth watching, especially if you’re considering trying out the language. After watching the video, I’m considering trying it out myself. There are a number of open source compilers available. The Glascow Haskell Compiler appears to be the favorite but there are others.

Posted in Programming | Tagged | 1 Comment

PDF Tools for Emacs

Over at Thoughts on Code and History, Matt Price has a nice post on Note Taking with PDF Tools and Emacs. PDF Tools is a replacement for DocView but with extended capabilities. Rather than build the PDF image in the file systems, as DocView does, PDF Tools builds it in memory and then allows you to interact with the PDF in various way.

You can get an idea of some of it’s capabilities from Price’s post and from the PDF README at GitHub. There’s also a video that gives an idea of some of it’s capabilities.

Sadly for those of us in the Cult, PDF Tools is supported only on Linux systems but the README does say that it has been successfully compiled under OS X. The README gives a couple of hints on how to do this. A Stack Exchange question indicates that it’s pretty easy to compile and use under OS X so if you’re interested it may be worthwhile giving it a try.

I haven’t used it yet but will probably try to install it shortly. I don’t use Homebrew—the recommended way of installing the tools—so I’ll either have to try compiling it by hand or install Homebrew. If anyone has installed it by hand, drop a comment and let me know of any problems or, better yet, lack of any problems.

Posted in General | Tagged , | 2 Comments

Capture Web Pages as an Org Structure

The other day, I wrote about using lynx to capture a Web page as text. Later, No Thanks had another, better, suggestion

This bit of Elisp leverages org-protocol to capture a Web page and insert it into an Emacs buffer as an Org structure.

This is, I think, a specialized use case but if it’s something you need to do, this could be a real time saver.

Posted in General | Tagged , | Leave a comment

Who Could Have Imagined…

this would happen?

Posted in General | Tagged | Leave a comment

The Publishing Workflow for ProGit v.2

As most of you know, I’m fascinated by publishing workflows. These days, my preferred scheme is write in Emacs/Org-mode and export to whatever final format I need. This strikes me as ideal.

Not everyone agrees, of course. Scott Chacon, one of the original GitHub developers and coauthor of Pro Git v. 2 has a different workflow. Unsurprisingly, he uses the Atom editor so he doesn’t write in Org markup. Instead, he uses Asciidoc, which is similar to Org but independent of any editor. Of course, these are just details. What makes his workflow different is how he leverages GitHub and the O’Reilly Atlas publishing toolchain.

Most of us won’t have access to Atlas but we can all use GitHub and leverage the methods that Chacon describes for collaboration and working with technical editors. I’ve written before about working as a technical editor and dealing with Word documents. I would much rather use the methods Chacon describes.

If you’re planning on writing a book—especially with one or more collaborators—be sure to check out Chacon’s post. He’s got a lot of good ideas. His workflow could easily be adjusted to work with Emacs and Org.

Posted in General | Tagged | Leave a comment

Org Ellipsis

It’s a bit silly, I suppose, but I really like this. It really does make things less cluttered.

Posted in General | Tagged , | Leave a comment

Capturing Links with org-protocol

A year ago, I wrote about how I quickly grab browser links and site links directly from Emacs. My solution leverages applescript so it’s usable only on OS X. Since I do all my writing on OS X, I’ve never bothered to figure out how to make it work in other environments.

Sacha to the rescue. She’s implemented something similar by using org-protocol. Her solution is for the Windows platform but should work, mutatis mutandis, for other platforms. If you’d like to do something along the lines that I did, Chua’s post may be a good jumping off place. I keep wanting to figure out org-protocol myself but every time I try, I get bogged down. Perhaps Chua’s post will help me finally figure it all out.

Posted in General | Tagged , | 2 Comments

Short History of Typesetting

If you enjoyed yesterday’s story about the vacation memo, you may also like another video by Professor Brailsford on a short history of typesetting. The Mergenthaler Linotron 202 that was the subject of my last post could be said to be a third generation typesetter. Bell Labs’ original CAT typesetter, with its optical fonts, was an example of a second generation typesetter. The Mergenthaler Linotype, a mechanical typesetter, is an example of the first generation.

Brailsford starts with an explanation of manual typesetting where the individual pieces of type were set by hand. He briefly covers the Linotype and then moves on to the second and third generation typesetters. They were all amazing machines but the most amazing, by far, was the Linotype.

It was completely mechanical but was able to take input from a keyboard, cast a line of (justified) type from molten lead, and then redistribute the type molds to the machine for reuse. If you want to see it in action you can watch the first 6 minutes of this 1960 film about the Linotype. That will give you a good idea of how complicated it was. If you have the time and want a real treat, watch the whole thing (it’s 35 minutes). After the short 6 minute introduction, the film explains in detail how it worked. It’s an astounding machine and by far the most complicated that I’ve ever seen. At the very end, they talk about the “future,” which involved driving the Linotype with paper tape.

The production values of the film are very dated by today’s standards but it’s still entertaining and informative. If you’re a nerd, you really have to watch it.

Posted in General | Tagged | 1 Comment