## Importing Tables to Org with Pasting

Ben Maughan over at Pragmatic Emacs has a nifty animation showing how easy it is to import data from a PDF by pasting it into a buffer and then using Emacs’ excellent tools to reformat it to the desired form.

## A DSL for Elfeed

As Irreal regulars know, I’m now reading my feeds with Elfeed. It put one more frequent task under Emacs and generally makes organizing and dealing with the feeds easier. Because of my Elfeed adoption, I’ve been paying more attention to news and articles about it.

One such article from last December is by Chris Wellons himself and describes one of the internal features of Elfeed. When an XML record describing an article or post arrives, the first thing that happens is that it is converted to an equivalent sexpr structure. From there, the necessary data is extracted and put into Elfeed’s database. That should be easy and, in fact, one could imagine making the sexpr process the data itself as I described back in 2011.

Sadly, things are more complicated. The RSS and Atom standards are a bit like the situation with Markdown: no one interprets them in exactly the same way. Data may be in one of several places and may or may not be encoded as you expect. Therefore, parsing the sexpr is non trivial. In order to avoid writing the same complicated code over and over, Wellons implemented a DSL that takes a description of the desired field within the structure. The DSL, which is sort of like a pattern matching description, is then interpreted by a pair of functions.

This can take some time. The example Wellons gives is searching for the data of an Atom entry. This may exist in 5 possible fields so he has a DSL entry to check each of those fields. As he added more features, the number of DSL entries that had to be checked grew and the process became slower.

This is where Wellons showed his genius. Rather than interpret the DSLs—parsing them over and over—he compiled them into Elisp byte code. That’s easy to do in Elisp because it’s precisely what macros are for. Basically, he replaced the two functions that interpreted the DSL with two macros that generated the same Elisp he would have written by hand. That change sped up the DSL processing by an order of magnitude and the entire XML processing by 25%. The processing is now dominated by the conversion of XML to the sexpr, which uses a function from the XML library and is out of his control.

See Wellons’ post for the details. If you like Lisp or ever wondered what the big deal about macros is, you’ll enjoy reading it. If you were wondering about macros, it will open your eyes. Really, go read it.

## 35 Coding Habits to Avoid

Christian Maioli Mackeprang has an interesting post on 35 habits that can negatively affect your coding. I’ll let you read them and make your own judgments as to their value for your situation but I’d like to comment on two of them.

The first, #20: Not bothering with mastering your tools and IDE, really resonated with me. Lately, I’ve spent more time than ever working on learning to be a more effective Emacs user. This is true even though I’ve been using Emacs for almost a decade. Every Emacs user knows there’s always something new to learn so you can probably never master the editor but the journey can make you appreciably more effective. I’ve found that the work I’ve put in has paid dividends that have more than made up for my effort.

The second bad habit, #22: Romanticizing your developer toolkit, is in some sense the converse of #20. I didn’t like it as much as #20 because it’s pretty clear that I am exceedingly attached to Emacs to the point that it is the epicenter of my workflow. Still, Emacs can’t do everything and, of course, I use other tools. Some of those tools make more sense for my workflow than using the corresponding capability of Emacs. I keep my calendar in the Apple Calendar app rather than any of the (perfectly adequate) calendar solutions in Emacs because it’s easier to sync it across all my devices and share some events with others.

For editing, though, I will always turn to Emacs. You can make the case that other editors or IDEs might be better for certain situations—the Racket IDE for Scheme or Eclipse for Java, for example—but the pain of switching to another editor and abandoning, even temporarily, my editor muscle memory means that Emacs is a better solution for me. Your mileage may vary, of course.

Posted in Programming | Tagged , | 2 Comments

## A Clojure Workflow

Manuel Uberti has a nice post that describes his Clojure workflow. What struck me is how generally applicable it is. Sure, if you aren’t doing Clojure you won’t care about Cider but everyone can profit from packages like, Projectile, Smartparens, Magit, Ivy, and ACUTeX.

Posted in General | Tagged | 2 Comments

## Russ Cox on Globbing

If you’re like me, you probably don’t think about globbing very much. It’s just a way of fuzzy matching file names in a manner reminiscent of regular expression matching. We all use it everyday but have you ever thought about its implementation or efficiency?

Russ Cox, of course, has thought about these issues and has posted a really interesting article with his results. He starts with a simple benchmark that measures the time to complete ls (a*)nb in a directory containing the single file a100  where the exponents represent string repetition. He discovered that this resulted in an exponential run time whereas ls | grep (a*)nb ran in $O(n)$ time.

Of course, globbing is done by the shell so he tried the (non-grep) experiment with different shells. Most shells showed exponential time but csh was linear in $n$. Cox also discovered that some FTP servers exhibit the same behaviors.

The results are odd because you’d think globbing is a much simpler problem than regex matching. It can be, of course, and Cox gives an example implementation that is both simple and fast.

Be sure to read the article to see all Cox’s results and analysis. As usual with Cox’s posts, it’s really interesting and well worth your time.

Posted in General | Tagged | 3 Comments

## Quick Check on Files With counsel-ag

The more I use swiper and counsel to more impressed I become. On reddit’s Emacs subreddit, the_whalerus asks how he can take a peak at files he found with counsel-ag to decide which one he wants to work on. As is often the case, abo-abo himself replied with the solution.

He gives two answers. The first and easiest is just to press or hold down Ctrl+Meta+n to check the buffers possibly skipping some with Ctrl+n or Ctrl+v. The other is to use ivy-occur by pressing Ctrl+c Ctrl+o and then choosing the desired files from the occur buffer. See abo-abo’s answer for more details.

You might not think this is worth remembering but to the_whalerus it was the difference between using ivy or switching to helm. If you often find yourself looking at the results of a counsel-ag search and trying to figure out which file(s) you want to visit, this tip could be just what you need.

## Dumb-jump in Action

The other day I wrote that I was considering installing dumb-jump and giving it a try. I did that and have been using it since I watched Mike Zamansky’s video on Projectile and Dumb-jump. It really is the sweet spot for me. I never liked TAG files and their associated machinery but dumb-jump doesn’t require any of that: it just works.

Recently, AT&T graciously released the source code for Research Unix v.8, v.9, and v.10. That’s a boon for us Unix aficionados who like to read code. I downloaded v.10 and started browsing. This is the first time I’ve had access to the source code for a modern AT&T Unix so I’m not familiar with the files layout. Fortunately, dumb-jump is just what I needed. All the kernel source files are in the sys directory so I put an empty .dumbjump file in sys and now when I’m looking at a function and it calls some other function in a different file, I can jump directly to it and then return.

I added two additional keybindings to the ones recommended in the README. For those who are interested, here is my configuration:

(use-package dumb-jump
:ensure t
:bind (("M-g o" . dumb-jump-go-other-window)
("M-g j" . dumb-jump-go)
("M-g b" . dumb-jump-back)
("M-g q" . dumb-jump-quick-look)
("M-g x" . dumb-jump-go-prefer-external)
("M-g z" . dumb-jump-go-prefer-external-other-window))
:config (setq dumb-jump-selector 'ivy))


You really want a binding to return to your jumping off place so I added that. I also added a binding for dumb-jump-quick-look, which gives you a short popup of the definition and some context.

The Unix kernel isn’t the largest project by any means but it is good sized. Nevertheless, dumb-jump found and moved to the target file almost instantaneously. I really like this package a lot.

## Org 9.0.7

Org mode has a bug fix out. I track Org on Melpa but if you don’t, now is a good time to update. If you do track Org on Melpa, the new version is there and ready for update.

## The Past Comes Due

Irreal oldtimers know that I have often railed about the activities of the NSA and their domestic spying and about the ever more shrill demands by law enforcement that they be given a back door into our cell phones. As everyone knows by now, the government’s sins have caught up with them.

Here are a couple of tweets from Edward Snowden that illustrate the problem

The NSA developed an exploit for Microsoft Windows and then lost control of the code, which was subsequently published on the Web. Criminals, of course, immediately used it to develop a ransomware worm which, among many other things, shut down several hospitals in the UK. I haven’t yet heard of any deaths resulting from this but it’s probably just a matter of time. In any event, it appears patient records may have been lost.

The US was largely spared but only because a UK security researcher stumbled on a kill switch for the malware and stopped it from spreading. You can read that amazing story in the link from the first tweet. Sadly, it appears that a new version without the kill switch has appeared.

I don’t believe it’s the slightest bit unreasonable to hold the NSA responsible for this mess—including any deaths that result. They wrote the exploit, they didn’t inform Microsoft of the vulnerability that made it possible, and then they let it get stolen. Someone should, at a minimum, lose their job but, of course, no one will.

That brings me to the second point. The government insists it can be trusted with a “golden key” to our smart phones and other devices. They say that of course they won’t abuse the capability and that we can trust them to keep the key out of the hands of criminals and hostile nation states. The WannaCry incident puts the lie to both those claims and justifies my belief that we should never trust the government with the access they desire.

Charlie Stross has an hilarious piece on the incident. He makes the point that if what happened were submitted as a piece of fiction, it would be rejected as unbelievable. He’s got a point.

UPDATE [2017-05-15 Mon 12:23]: Yoni Heisler agrees.