Irreal

Over at Emacs Redux, Bozhidar Batsov has a nice post on Emacs debugging commands. It’s not the first time that I’ve written about this sort of thing (see here, for instance) but unless you’re actively developing in Elisp, you probably aren’t going to need these techniques very often.

Still, all of us sometimes experience an Emacs command aborting with an error. Usually—not always, but usually—this isn’t a software error but results from a misconfiguration or at least an usual configuration. Most Irreal readers probably have enough technical chops to do some simple debugging and resolve the problem without reaching out to experts. The value of Batsov’s post is that it provides a short recipe for doing that.

The first thing to do is to enable debug-on-error. That will give you a backtrace to help you see where your command is failing. Batsov says you can turn this on permanently in your init.el but I found that this dumped me into the debugger for mundane errors that were caused by user input. It’s better in my opinion to enable it temporarily and rerun the command that’s misbehaving.

“Backtrace” may seem a little scary but often seeing what functions are being called and what their arguments are will tell you immediately what the problem is. You definitely don’t have to be an Elisp expert to take advantage of this.

If debug-on-error is not enough you can set a breakpoint on the problem command and step through it. That really does sound scary but it’s not. Batsov gives a simple 4-step procedure to set it up and tells you how to step through the code. This is almost always enough to find the problem.

There is, as Batsov says, a lot of built-on debugging capability in Emacs and it’s worthwhile getting familiar with it.

James Dyer has a short post on replacing some embark functionality with his own code. He does a nice job and you can check his post for the details but his post again raises the issue of why some users go to heroic lengths to avoid loading packages from ELPA.

Dyer’s stated rationale is that his system is air-gapped so of course he doesn’t want to be pulling down code from the Internet. I’m doubtlessly missing something essential here but that seems to me to present a chicken-egg problem. How do we bootstrap Emacs onto an air-gapped system? And whatever method we use, why can’t it also be used to install third party packages?

To be sure, there’s the problem of keeping things upgraded but that applies to Emacs too so, again, what’s the point of all this?

The last couple of times that I broached this subject [1, 2] some commenters schooled me on why, in certain circumstances it makes sense to avoid third party packages. Perhaps Dyer’s air-gapped system is one of those circumstances but I’m still having a hard time seeing how it solves any substantive problem.

What I do understand is the desire to try implementing these functions yourself. NIH has a bad rep, of course, but let’s face it, every developer can fall prey to it. Of course, Dyer isn’t saying that’s what he’s doing; he’s just trying to configure an air-gapped system.

Dyer is a regular poster and his posts have always made sense so I’m sure this one is no different. I just can’t figure it out.

Joshua Blais has a nice video that recounts an apostate’s repentance. Blais was an Emacs user but moved to Neovim. Users always seem to be switching back and forth between Emacs and Vim. They are, after all, the only two serious editors.

The point of this post, however, is not to gloat but to tell the story of Blais’ return to the fold and the reasons for it. The TL;DR is that Emacs provides a total operating environment. That it is, in fact, a Lisp Machine.

He examines in depth the frequent complaint that Emacs has a long learning curve and points out that the comparison is unfair because the learning curve of Vim, say, doesn’t include having to learn all the other applications you need. One of the strengths of Emacs is that it presents a uniform interface across all its applications. One you learn it, there’s little effort involved in learning another Emacs app.

In the Emacs subreddit, Karthink, who has more than earned our respect, makes a bit of fun of Blais for his apostasy but I’m willing to take him at his word. There’s a lot to be said for Vi and its siblings and for some users it’s the right choice. But if you want a total operating environment with a uniform interface, then Emacs is probably the right choice for you.

The video is 20 minutes, 54 seconds so plan accordingly but if you are undecided about which editor to use, it’s worthwhile spending a few minutes with his video.

A couple of weeks ago, I wrote about a reddit post that asked what computer/OS people were using. Nuno M. Salgueiro replied that he was not a programmer or even in IT but that he used Emacs at home on Linux and at work on Windows. This, of course, immediately piqued my interest because I’m always interested in how people who are not programmers or otherwise involved in IT use Emacs.

I asked Salgueiro to expand on how he uses Emacs and he obliged with an excellent discussion of how and why he uses Emacs. I encouraged him to make that into a blog post or at least let me publish it for him. He didn’t seem interested in pursuing the life of a blogger but kindly invited me to post his reply. I thought it was too interesting to be lost in the comments, so here it is, exactly as he wrote it:

In my daily work in a logistics company, I use Emacs to organize nearly everything I do. It’s so central in my workflow that I dedicate an old LCD monitor in vertical orientation just for it.

Most of the stuff I do is in org mode: it’s a record of the knowledge I’ve acquired over the last 15 years; it’s my agenda and TODO list; it’s what I use for taming meetings and taking quick notes; it’s where my projects live, and where thousands of links allow me to open instantly the relevant emails in MS Outlook. Org mode is powerful enough to look like magic when colleagues are by my desk (“Wait, how did you do that?!”). Yes, I’m not above the mundane pleasure of showing off Emacs to innocent souls. ;)

Keyboard macros with a very basic knowledge of regexps is a powerful enough combination to sometimes have colleagues sending over their files and asking me to use “that tool you have for text” to do work in a couple of minutes that would’ve taken them hours. Compared with it, macros in Excel feel like a child’s toy.

I use Dired only sporadically because Windows is a terribly slow environment for it. I get by with Double Commander, an orthodox file manager, which is good enough for my needs. At home, Dired is my file manager.

Another big one for me at work is taking notes on PDFs with org-noter. It’s simply amazing because I don’t need to change the file itself, I just keep all the notes in separate org files in the same folder. This is only for own consumption, of course, but it’s good enough to justify its own workflow.

At home I use org for my diary, as well as its powerful attachment functions all the time. All kinds of documentation for the house/car/health, important receipts, etc., all that is kept in their subtrees with all the necessary context. I wish I could use that at work. sigh

Finally, I used to keep my personal accounting with ledger mode, but never got the will to search for some data importing tools. I was typing everything by hand but it got too repetitive, even using YASnippet. Maybe one day I’ll find something to speed it up and get back on it.

Using Emacs in a work environment void of programmers or software-oriented people is strange. Colleagues look at it and see what seems to be an old text editor, but you suddenly press a few keys and, to their eyes, something amazing happens—maybe it’s a text manipulation that’s impossibly fast in their Word world, or it’s finding the desired information and links in a matter of seconds, or jokingly popping up a game of Tetris—it doesn’t matter, they’ll look at it as something entirely alien to their experience and, most importantly, they have a glimpse of the possibilities. It’s quite a thing to see.

A huge THANK YOU for your blog. I never miss an article of yours (Elfeed is a beast), and I’ve been learning a lot from them already for years. Whenever I see something that could work well for me, I try it. Along the way I learned a little bit of Elisp, enough to be able to integrate pieces of code I find online into my config. When it fits my needs, it’s an absolute joy, a feeling I’m certain many of your readers share.

It is, I think, an excellent discussion of how Emacs can be for everybody and how those who believe Emacs is old and outmoded are invariably amazed at what it can do in the hands of an knowledgeable user. Thanks to Salgueiro for sharing his experience with us.

Charles Choi is back with another app in his Casual Suite. This time it’s for dealing with images from within Emacs. As Choi says, there are better ways of dealing with images than from within Emacs but for those of us addicted to the Emacs flow, the less than optimal UX may be worth it. Thus: Casual Image.

The idea, as with all the Casual apps, is to provide an easy to use transient menu for dealing with hard to remember, esoteric commands. In this case it’s for the built-in image-mode.

Again, Emacs may not be the best way to deal with this problem but it does allow us to stay within Emacs and leverage the power of our favorite editor. Choi says that this Casual app is more opinionated than usual because image-mode’s commands are particularly poorly named so Casual Image renames them. Take a look at the menu on Choi’s announcement, linked above, to see what he means.

The only downside to Casual Image that I can see is that it requires ImageMagick to be installed. That’s not much of a downside given that you’re dealing with images. If you deal with images all the time, there are probably better ways of dealing with them but if it’s an occasional thing and you like staying in Emacs, Casual Image may be just what you need.

Protesilaos Stavrou (Prot) has another really excellent video up. This time it’s about organizing your Emacs configuration file. Prot looks at two possible approaches. The first is to use the built-in outline mode and appropriately marked comments to have an Org-mode-like presentation of your init.el with section folding and easy search.

The second approach is probably the most common today. It’s to write your configuration file as a literate Org document and tangle the code into the file that Emacs loads at startup. There’s a lot to be said for this approach. You can completely annotate your configuration with what it’s doing and why it’s doing it in that particular way. That’s especially useful if you want to share your configuration. You can export it to HTML, PDF, or even something like Docx. It is, after all, just another Org document.

All of that is old news, of course, but the real benefit for me from Prot’s video is how you can start with a traditional init.el and transform it into a literate Org document. The nice thing is that this can be done piecemeal so that you can convert it bit by bit over a period of time.

It’s pretty easy. First just put the whole init.el into a single code block in the new Org file. You can add a title and perhaps some introductory comments. Finally add a property that tells Org where to tangle the file and you can generate your init.el directly from the new Org file.

The key to breaking the Org document into sections is the org-babel-demarcate-block command. This command splits the current block into two distinct blocks so that you can add headers and commentary between them. Take a look at Prot’s video to see the process in action.

If you’ve ever thought that you’d like to have a literate Emacs configuration file, Prot’s video is what you need. He shows you how to start with what you have and incrementally change it into a complete literate document.

Way back in 2005, Steve Yegge wrote a wonderful post, the-emacs-problem, that discussed why Lisp is the right language for dealing with text and why Emacs is the right tool for dealing with it. A few years later I wrote a post discussing Yegge’s post.

Recently, someone reposted Yegge’s original post and since it was so long ago, I thought it was worth revisiting. Although Yegge makes several great points, the key insight for me, is that a log file structured as S-expressions can be thought of as a program. Sure, the symbols in the function slots may not actually be functions but they can be.

I explored this a bit in in a post that looked at how to make the log file executable. It turns out to be incredibly easy and amounts to little more than defining a function for each of the tags in the function slots. The next two posts push this idea further and show how it can be easy to use the same idea to filter log entries according to some criteria. The thing to remember is that the log file started life as simple data and it was merely a change of view that allowed us to think of it as a program.

This set of posts are among my favorite Irreal offerings and, I think, make the oft quoted Lisp adage that “data is code” (and vice versa) come alive. If you really want to internalize the equivalence between Lisp code and data, read Yegge’s post and follow up with my posts. They’re over 13 years old now but, I think, have stood up well.