If you do a lot of your writing with Org mode the way I do, you may sometimes need pandoc to help with exporting your work. If you are one of those people, Karl Voit has some good news for you:
#pandoc 1.17.1 released with lots of improvements for #orgmode https://t.co/f9EPzCjG2l
— n0v0id (@n0v0id) June 5, 2016
If you haven’t upgraded up yet, head over to the pandoc site and get the new version now. They have prebuilt packages so installation is easy.
Those of us in the US have ample reason to despair of our legislators’ willingness to collude with the NSA in the evisceration of the Fourth Amendment. But at least our congress draws the line when it comes to spying on them. Sadly, the same is not true of our cousins in the UK.
Computer Weekly is reporting that MPs’ private emails are routinely accessed by GCHQ. Yet Parliament goes right on passing draconian surveillance bills. The MPs are even moving ahead with the Investigatory Powers Bill that would expand GCHQ’s abilities to snoop on UK citizens.
What does it take to make Parliament finally say enough is enough and rein in a clearly out of control GCHQ? The MPs are theoretically protected by the Wilson Doctrine, which says that MP communications are off limits without consent from the MP involved. However, a recent move to Microsoft Office 365 for Parliament’s email means that the email is often routed through Microsoft datacenters in Ireland or the Netherlands. Since that means the messages leave the UK’s borders, the GCHQ has felt free to scan MPs’ messages including those from constituents.
When the new system was being planned, there was some concern about this sort of thing happening. MPs were assured that while there might be some risk, it was low and acceptable. One’s tempted to say they deserve what they got except they don’t. MPs are the nation’s law makers and they certainly deserve to have their private communications remain private. Again, what will it take before they start insisting on that? What will it take before Britons, generally, insist on the same?
The ludicrous and unworkable Burr-Feinstein bill appears dead, a victim of its “do magic somehow” prescriptions and a lack of support from the White House and intelligence agencies. Nonetheless, we can expect more of the same perhaps even from the same know-nothings that gave us Burr-Feinstein.
Daniel J. Weitzner (and others) over at the Lawfare blog have a nice checklist to help evaluate new backdoor proposals. The six items on the checklist are not so much technical as common sense. For instance, number 6 is “Watch for the assumption that human rights and the rule of law prevail throughout the world.” Taken together, the items represent a high but minimal bar that any proposal should meet.
Since the checklist non-technical, it would be nice if our legislators would consult it before churning out more irrational and unworkable legislation. On the other hand, it is, as I say, common sensical so they probably won’t.
Frédérick Giasson has a nice post in which he describes how he uses Org mode to run unit tests on his code. Actually, his goal is to combine the writing, documentation, and testing of his code in a single document using a single tool.
His mechanism for this is to use Literate Programming in Org and to put the tests in the same file next to the function that they’re meant to test. He describes this in terms of Clojure but the technique is obviously generally applicable.
One possible problem with this procedure is if you’re working in a team and not everyone is an Emacs user. Non Emacs users won’t be keen to tangle an Org document to get the code and probably won’t feel comfortable making changes to an Org file. Unless everyone you’re working with is an Emacs user or you’re working alone, this means that Giasson’s workflow will have to be limited to initial development. Still, it’s a powerful technique and well worth experimenting with.
One of the things that always causes confusion and that is hard to find in the documentation is making date calculations in Org. I was reminded of that when I saw a reddit question on making date calculations in an Org table. The comments to the question give some useful hints.
After I read the reddit query, I remembered that Sacha had, of course, already already covered this material so you should take a look at her post too. One of the things that Sacha points out is that it’s important to use “proper” Org dates—that is, active or inactive dates with the […] or <…> brackets. That ensures that you can perform arithmetic on them directly without having to worry about converting from string to date.
As I said, these two posts are useful because it’s hard to locate the documentation that covers the subject. Once you get in the habit of storing information like this in Org tables, you’ll find that techniques like these are really useful.
Like me, Artur Malabarba is a heavy user of fill paragraph. I don’t use visual-line-mode when I’m writing so every time I make an edit I refill the paragraph. Malabarba apparently does the same but being Malabarba has found a way to improve things.
He says that sometimes he wants to unfill a paragraph and would like an easy way of doing that. He noticed that there’s no reason to call fill-paragraph twice in a row so he wrote a bit of glue code to check if the last command filled the paragraph and if so to set fill-column to point-max, which causes fill-paragraph to unfill the paragraph. Finally, he remaps 【Meta+q】 to call his glue code.
If you, like Malabarba, sometimes find yourself needing to unfill a paragraph, head on over to Endless Parentheses and copy his code.
Kontra has a nice quote from Vernon Sanders Law:
"Experience is a hard teacher because she gives the test first, the lesson afterwards."
— Kontra (@counternotions) May 30, 2016
A year ago, Mickey Petersen published Mastering Emacs, an excellent book for beginning and intermediate Emacs users. Oddly, although I’ve seen many tweets praising it, I haven’t seen any reviews. Happily, the prolific Artur Malabarba has remedied that.
If you don’t already have your own copy of Mastering Emacs, take a minute to read Malabarba’s review. I’m sure it will convince you that you’re missing out. Even if you’re relatively familiar with Emacs, you’re almost certain to learn a few things. I know I have.
Back in 2012, I wrote a blog post recounting my observation that the best developers tended to use either Emacs or Vim (and back then, possibly TextMate on OS X). I speculated that that might be because excellent developers choose the best tools available and invest in learning to master them.
Now, Sébastien Le Gall writes that developers in 2016 must learn Emacs or Vi. His post fleshes out my arguments for why great developers and those that want to be one take the time to master Emacs or Vi. He looks at two features in particular:
Some of you will doubtless disagree as you did with my analysis but Sébastien’s post is interesting and might encourage non-users to give Emacs or Vi a try.
Al Scott is an Emacs user and JavaScript developer who’s interested in using the TDD method. He likes to use Mocha to run JavaScript scripts for testing. Unfortunately, there’s no easy way to do that from Emacs so Scott decided to write a custom package, tied to the Emacs compile command, that would implement a Mocha test runner. His post walks us through the steps needed to write such a package.
Scott starts by noting that Emacs comes with a lot of built-in facilities to ease Elisp development and that by adding a couple of packages like flycheck and company-mode you have a pretty complete IDE for Elisp. The purpose of his Mocha-runner is to bring some of the same capabilities to JavaScript development.
The rest of the post shows the step by step development of writing the package. He even mentions the steps needed to add the package to the MELPA package repository. Even if you’re not a JavaScript developer or interested in TDD, there’s a lot of useful information in the post and I recommend it to any Elisp developer.