Henry Spencer and getopt

Posted on 2017-05-27 by jcs

Kids today! They have it so easy. (Waves cane.) Eric Raymond (esr) has posted a charming vignette that, among other things, illustrates how easy we have it today. The story is set in 1984 when AT&T had just announced that it was going to commercialize Unix. There was great anxiety among the small group of Unix hackers that access to the Unix source would dry up. This was before the GNU manifesto and there wasn’t really such a thing as the open source movement as we know it today.

During a Usenix/UniForum conference, a speaker from AT&T was describing the new getopt function that was intended to bring uniformity to command option processing in the Unix world. Several of the participants pressed the AT&T speaker on whether everyone would be allowed to use this new functionality and were met with evasions. At this point Henry Spencer stood up and announced he would write and share with others his own conforming version.

Esr notes that in many ways this was the start of the hacker/open source culture that we’re familiar with today. A public refusal to put up with having corporations or anyone else lock away source code. It’s easy to imagine that things have always been the way they are today. But that’s not true. As I mentioned the other day, AT&T recently released the source code for Research Unix v.8, v.9, and v.10 but, believe me, things were not always that way. Guys like Spencer and Raymond worked hard to create the world we live in today.

Posted in General | Tagged | Leave a comment

Fontifying Completed Checkbox Items

Posted on 2017-05-26 by jcs

Matus Goljer (Fuco1) has another excellent suggestion in his latest blog posting. A recent project required a large list of tasks to be completed, which he tracked with Org mode checkboxes. The problem was that it was visually confusing and hard to see clearly the items that still needed to be done. Fuco1 solved that problem by arranging for the completed checkbox items to be displayed in the org-headline-done face. With his theme, that’s a grayed out rendering and easily distinguished from an uncompleted task.

That’s pretty nice but I’m so far behind I didn’t even know about the org-headline-done face or how to use it. Out of the box, Org will display completed headlines (DONE, etc.) in that face if you set org-fontify-done-headline to t. I’d never heard of that so I manually set org-fontify-done-headline to t in the minibuffer to try it out. I’m pretty happy with the result and will probably make it permanent by moving it into my init.el.

Even if you don’t have long task lists, you might like turning the feature on to make completed TODO items stand out. It’s easy to try out temporarily by just turning it on from the minibuffer. If you like it, you can make it permanent.

Posted in General | Tagged , | Leave a comment

A Nice Trick for Literate Configurations

Posted on 2017-05-25 by jcs

Marco Wahl has a nice Emacs literate configuration that’s worth taking a look at for some of his ideas. What I really like, though, is his trick for making the tangled init.el read-only to remind himself and others not to directly edit the init.el itself. The trick is explained in this tweet from Wahl:

You can see how he does this by looking at the first line section of his configuration. He just puts that first line in its own code block at the beginning or the Org file. If you’re still in doubt, just push the Raw button to see the actual Org source.

Posted in General | Tagged , | Leave a comment

Using Org Mode for Writing

Posted on 2017-05-24 by jcs

Over at the Emacs subreddit, willmhorne asks how people use Org’s outlining capabilities for essays, books, and other long-form writing. Most Org users have their own answers to this but it’s very interesting and useful to see what others have to say. I especially liked rpdillon’s and kbouser’s answers. They have a developed an organized process that makes writing and sharing as painless as possible.

One of the big problems, especially for writers in the humanities, is sharing work with colleagues who are most likely using Word. A couple of the respondents address that question as well. The best solution I’ve seen for this was captured by Grant Rettke from the Emacs-Orgmode mailing list. It’s a little complicated but could probably be automated fairly easily. It’s perfect for coordinating with coauthors who have the poor taste or misfortune to be using Word or one of its evil siblings.

Posted in General | Tagged , | Leave a comment

Importing Tables to Org with Pasting

Posted on 2017-05-23 by jcs

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.

Posted in General | Tagged , | Leave a comment

A DSL for Elfeed

Posted on 2017-05-22 by jcs

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.

Posted in General | Tagged , | Leave a comment

35 Coding Habits to Avoid

Posted on 2017-05-21 by jcs

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

Posted on 2017-05-20 by jcs

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

Posted on 2017-05-19 by jcs

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.

UPDATE [2017-05-22 Mon 08:21]: Added link to article.

Posted in General | Tagged | 3 Comments

Quick Check on Files With counsel-ag

Posted on 2017-05-18 by jcs

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.

Posted in General | Tagged | Leave a comment