Remember This?

Unless you are really young, you probably remember a spate of capacitor failures in electronic devices of all sorts including computer motherboards. This was around the turn of the century. One of my family members practically had a production line going where he unsoldered a broken capacitor and put in a good one that he happened to have around. He wasn’t even all that particular about the farad rating but everything always worked fine afterwards. It was a real pain for a while but then it went away without me—at least—noticing. Here’s a hint at the backstory:

If you follow the link at the bottom of the tweet, you can read the whole story including what was going on. It’s pretty interesting if you’re Geek 30, say, years or older.

Posted in General | Tagged | Leave a comment

You Can’t Make This Stuff Up

I can’t decide if this is a joke or if someone is actually that clueless. It’s not April 1st so I’m reluctantly concluding that it’s for real1. I’m sure Miessler was surprised to learn that he’s maintaining the master password list for “hackers.”

Footnotes:

1

Well, actually, I still can’t decide. On the one hand it’s “too good not to be true” but on the other the guy has enough knowledge to file a GitHub pull request and his GitHub repositories do indicate he’s got some programming chops. And, really, who’s that naive?

Posted in General | Tagged | 1 Comment

I Am Not Worthy

I used to feel pretty snug when I got up to around 100 open buffers in Emacs. Not anymore:

Posted in General | Tagged | 6 Comments

Org 9.1.5

Over the holidays, Bastien Guerry announced a new Org mode version: 9.1.5:

Another nice Christmas gift from the folks in our community.

I just checked and it’s already in Melpa. It’s a bug fix so if you like to keep things clean you can update now.

Posted in General | Tagged , | Leave a comment

Zamansky 39: mbsync and mu4e

Speaking of Christmas gifts, Mike Zamansky has just posted the latest video in his Using Emacs series. This time he talks about setting up mbsync and mu4e to handle his email. I went through that same exercise and can testify that it’s hard to figure things out so Zamansky’s video is a welcome addition to the how-to corpus.

From this video I learned how to do something I’ve often wanted to do but didn’t know was possible: compose an Email using Org mode. Like Zamansky, I usually just compose emails in plain text but sometimes it’s nice to be able to use some of Org’s features while composing an email. Sadly, markup like italics and bold didn’t get exported correctly but things like tables and source blocks did.

As I’ve said many times before, I really love using mu4e for my email and recommend it to anyone who’d like to handle email from within Emacs. If you’re interested in trying it out, Zamansky’s video and post are good resources for getting started. The video is about 24 and a half minutes so plan accordingly.

Posted in General | Tagged | Leave a comment

OrgMode Tutorial Episode 7, Snippet 5

It’s Christmas Eve and Rainer König has just landed his sleigh on the roof of the Irreal International Headquarters with a gift. After a long absence, he’s back with another episode of his OrgMode Tutorial video series. This time he looks at goal setting and tracking.

König considers two ways of using Org mode for recording and tracking goals. The first uses the PROPERTY drawer to set the type of goal in a normal TODO type file. König shows how to use column view to easily set and maintain these settings.

Then König considers the strategy of using a separate goals.org file. In this solution he uses a custom capture template to easily capture a series of fields for each goal. It’s a nice example of using a “fill-in-the-blanks” capture template that would be useful in many different applications.

The video is just a bit over 20 and a half minutes so you’ll probably have to schedule some time. It’s a nice example of using Org mode for one of its signature type of applications.

Posted in General | Tagged , | Leave a comment

Steve Purcell

Like most Emacs users, I depend on Melpa to install my packages and keep them up to date. I have a couple of packages from the other repositories but the majority of them come from Melpa. It’s easy to get grumpy when something goes wrong: there’s a build error, there’s a missing file, a package takes a while to get into Melpa, and so on.

The truth though, is that Melpa is a volunteer operation run by Steve Purcell. Everything that happens on Melpa happens because Purcell or one of his helpers spent their time doing it for free. I was reminded of that by this thread on Twitter:

If you click on the tweet, you’ll see that it started with Purcell saying he was 18 days behind in dealing with pull requests. To deal with that, Purcell spent 3 and a half hours on a holiday weekend to clear the backlog. As Murray says, we all owe Purcell thanks for a job well done and for donating his time for this unpaid but very important work.

Purcell lives in New Zealand so most of us are unlikely to run into him but if you do, be sure to give him your thanks and buy him a beer. It’s the least we can do.

Posted in General | Tagged | 1 Comment

Comments

One of the perennial programmer arguments—not quite up there with Emacs v. Vim but enduring nonetheless—is whether or not we should comment our code and if so, how. some folks say that the need for comments is a code smell: an indication that the programmer did not write the code clearly enough. If the code is clear and well-structured, they say, there is no need for comments.

I’ve been doing this long enough to know the truth of this bit of programmer wisdom. Sometimes I’m lazy and don’t adequately comment. I’m always sorry later. Nate Finch has an interesting post that claims this is always true. For everyone.

Finch says that except for trivial examples there are no bad comments. Some may be superfluous but even in that case they don’t really hurt anything and are certainly better than not commenting at all. At the other end of the spectrum, Finch says that the most useful comments are the “why” comments. These are the comments that tell the reader why you’re doing what you’re doing. They’re important because they capture domain knowledge that’s not implicit in the code itself.

In the comments (heh), John Martin observes that the ideal of self-documenting code is never realized in practice. Except, again, in trivial cases I think that’s true. This bit of Elisp:

(defun add-a-to-b (a b)
  (+ a b))

could, I suppose, be called self-documenting but any serious piece of code is unlikely to be so.

So the TL;DR for this post is: I agree with Finch. Comment your code.

UPDATE [2017-12-23 Sat 15:13]:

I was rereading this post and noticed that my example of “self-documenting” code inadvertently made the Martin’s larger point. I intentionally wrote it to be so obvious that no comments were needed but on rereading it I realized that I chose a misleading name, add-a-to-b. That name suggests something like \(b \leftarrow a + b\), which is not, of course, what the code does. So it turns out that writing self-documenting code even in trivial cases isn’t that easy.

Posted in Programming | Tagged | 1 Comment

flet, cl-flet and Dynamic/Lexical Binding

This is a post for Elisp programmers who have some Common Lisp (CL) experience. One nice feature of CL is the flet macro that lets you temporarily bind a function lexically. Emacs Lisp also has a flet in the cl library but it’s slightly different in that the binding is dynamic. If you’re not clear on what that means Chris Wellons has a nice discussion of the difference and a practical example of why the difference matters.

In Emacs 24.3 the cl-lib library was introduced to replace the cl library. Mostly that amounted to renaming the functions to have a ‘cl-’ prefix but cl-flet differs from flet in that the binding is lexical as in Common Lisp. In general, that’s a good thing because it makes Elisp consistent with CL as far as flet is concerned and is almost always the desired behavior. It turns out, though, that the old behavior was useful in certain circumstances such as stubbing out functions during testing.

Happily, there’s an easy solution. Both Wellons and Artur Malabarba explain the problem and the solution. Malabarba’s post is short and to the point while Wellons explains things in more detail. If you’re a serious Elisp programmer you should definitely read both posts. There’s a lot of confusion about flet and cl-flet and the two posts linked above do an excellent job of clearing things up.

Update [2017-12-22 Fri 13:36]: flexflet; cl-flexcl-flet

Posted in General | Tagged , | 3 Comments

Git-undo

John Wiegley has released a nice package that can be really helpful if your workflow involves tracking and saving your work with Git. Sometimes you do some work and then decide that you don’t want that change and would like to revert back to what it was. Wiegley’s git-undo makes that easy. You can mark a region and have that region replaced by the working tree or HEAD version of your Git tree. You can also walk back through your Git history undoing previous changes to the region in your Git tree.

It’s not yet in Melpa but it’s a single small file so perhaps Wiegley has no plans to submit it.

Posted in General | Tagged , | Leave a comment