— nixCraft (@nixcraft) June 24, 2015
— nixCraft (@nixcraft) June 24, 2015
This is exactly how I think of Emacs
"Emacs is a Lisp VM with built in primitives for handling its fundamental data structure - buffers (of mostly, but not always text.)"
— unbalancedparen (@unbalancedparen) May 13, 2016
It's almost a cliché but Emacs really is much more than an editor. It's the way I organize my workflow.
Charlie Stross was browsing through an old, recently declassified OSS manual on sabotaging the enemy's production and started wondering about how you could apply the same principles to sabotage your competitors by injecting bad policies into their environment. He lists 10 policies that, if adopted, would tend to destroy an organization.
First on the list is Irreal's longtime favorite policy for destroying morale and productivity: open plan offices. The others would be equally effective at causing mayhem in your competitors' offices. Be sure to read the list.
Then read the comments. Warning: there are a lot of them—155 at the time of this writing. The comments are in response to Stross' solicitation of further ideas. The result is a catalog of all the dysfunctional ideas that “management consultants” and other criminals have foisted off on our work places. You'll probably start off laughing but by the end you'll be shaking your head with tears in your eyes.
Most of these ideas are so ridiculous that your first thought is that no one would implement them. Then you'll remember about open plan offices. Or, if you're really unlucky, you'll remember that awful company you used to work for—or maybe still work for—that does have policies like these. One of the most telling comments notes that the commenter no longer considers Dilbert funny because it just documents what is happening in many companies.
It's an enjoyable post made all the more so if you have time to browse through the comments.
The other day I wrote about using the SIGUSR2 signal to quit Emacs. It's usually enough to unjam Emacs and get you into a state where you can at least save your work and restart Emacs.
Marcin Borkowski (mbork) has a very nice post that explores the use of SIGUSR2 and how it interacts with the debugger. If you're developing in Elisp and often find yourself hung, some of mbork's techniques may help you figure things out. It's an informative post and well worth taking a look at.
Once you've used Lisp—especially Scheme—you come to regard tail recursion as a natural and necessary technique. Perhaps even a God given right. Sadly, leave the Lisp world and you're pretty much out of luck. Of course, you can always make a tail call but that quickly fills up the stack. What we're talking about is sometimes called tail call optimization (TCO). With TCO, the function call in the tail position is replaced by a
goto and nothing is pushed onto the stack.
Marc Simpson over at 0branch blogs about one of the rare exceptions to the Lisp-only rule about TCO. In gawk—but not in nawk or mawk—there is a limited type of tail call optimization but you have to take steps to enable it and it only works in restricted situations. Still, it's nice to know it's available if you really need it. Head over to the post for the details. They're not earth shattering but it is nice to know.
Howard Abrams has a nifty video on his setup for invoking remote shells. Those of you who have followed his recent videos know that he works with a lot of virtual machines and it is convenient for him to be able to swiftly connect to them—from within Emacs, of course.
To do that he first builds a hash table (this happens automatically) mapping host nickname to IP address or fully qualified domain name. Then he does a completing read to get the nickname, and hence the IP address or FQDN, of the host he wants to connect to. The rest is easy: he essentially executes the code
(defun remote-host (host) (let ((default-directory (format "/%s:" host))) (shell host)))
host is the result of the hash table mapping.
Notice the nice trick here. By setting
default-directory to a remote host,
tramp is automatically invoked and you're running a shell on the remote machine. By setting
default-directory to something like
/ssh:host|sudo:host: you can invoke the shell as root. See Abrams' code for the details.
Naturally, his setup is a little more complex but this captures its essence. He also has a function to run a command on a remote host using the same strategy but calling
shell-command instead of
shell. He even shows how to run the same command on a list of remote hosts all automatically. You can see how this would be useful if you're administering several machines.
In the video, he doesn't spend a lot of time going over the code so you'll want to check it out at on his github. The video is only 6 minutes 42 seconds so you can enjoy it during a coffee break. Highly recommended.
UPDATE: Fixed link to the github code. Abrams → Abrams'.
If you're paranoid about the security of your email or if you occasionally have the need to send secure messages to someone, the grugq, a well known and frequent commenter on security matters has a very nice gist on securing your email with PGP/GPG.
It's not another in the long list of articles on configuring PGP/GPG but more of an opsec guide to using them securely. A large part of that is controlling the metadata. For example, one of his suggestions is to leave the subject blank or at least make sure it doesn't refer to the content of the email in any way, even obliquely.
Another pointer is to not publish your public keys to a keyserver. Send them to your recipients only. The gist tells you how to do this securely. It's also a good idea, he says, to have several keys and to destroy and replace them frequently. This helps deal with the fact that PGP/GPG don't have perfect forward secrecy.
There are a lot of good ideas in the article so it's definitely worth taking a look at it if you have a need for secure email.
Munen Alain M. Lafon has a nice post on using an Org capture template to record a bit of source code. I like it because it's completely self-contained. You just define the template and it works.
The real value of his template may be the ideas it demonstrates. He shows how to capture tags for the entry as well as the language the code is for. It uses the same ideas as Michael Alan Dorman's commnet to my post from last week.
On the other hand, if you have a use case for capturing and saving bits of code for later use, you'll probably find Lafon's post useful on its own terms. It's a short post and worth taking a look at even if you aren't interested in capturing code snippets.
Chez Scheme has always been an excellent Scheme implementation. It produces very fast object code and is a complete R6RS implementation with extensions. Chez Scheme was written by Kent Dybvig, who also wrote the excellent The SCHEME Programming Language (also available online).
The problem has been that Chez was a proprietary, closed system. Now Chez has been opened sourced. If you are a Schemer, you may want to take a look. I haven't built it yet so I don't have a take on how hard that is, but these directions make it look pretty simple: perhaps as simple as a
If you're interested in learning Scheme, Dybvig's book and Chez Scheme are an excellent way. And now you can get both at no cost. The CONTRIBUTING and CHARTER files indicate that Chez Scheme is an ongoing project that welcomes new developers. The open sourcing of it is really good news for the Scheme community.
Eli Bendersky has an outstanding post on multiple dispatch in Common Lisp. It's part of a series he's doing on multiple dispatch in various languages.
Lisp has always looked at OOP differently from most languages and Lispers consider CLOS a superior way of doing things. One of the ways it shines is in multiple dispatch. With CLOS, multiple dispatch is just a natural outcome of the way dispatch works.
The post is an excellent overview of CLOS in general. If you want to know what OOP looks like in Lisp, be sure to take a look at Bendersky's post. In Lisp, OOP is easy and natural and works well in those cases where OOP makes sense. Even if, like me, you generally don't care for OOP, you may find that CLOS will change your mind. On the other hand, as Paul Graham says, Lisp is the language where OOP is least necessary.