Irreal

Bozhidar Batsov, the developer of projectile, has announced some updates to its caching behavior. The idea is that a projects files are cached so that they don’t have to be reindexed every time your bring up a project.

Projectile has always done this, of course, and it works well but Batsov has always had in mind some improvements and is now getting around ti implementing them. His post is interesting because it gives us a window into his thinking. It’s always instructive a have a good developer explain his choices and his thinking.

Take a look at his post to see what I mean. Batsov says that most people have probably abandoned projectile for project.el but he believes that projectile still has some things to offer. I’m not in a position to say but I am a fan of Batsov’s work, especially in this area.

As you all know, I’m a huge fan of Org mode and use it for virtually all the writing I do. One of the powers of Org is that you can export it to many different formats. One of those formats is the Borg Word. I always make some facile statement like, “and you can export to Docx if you need to produce a Word document.” But, of course, the reality is a bit different.

Chris Maiorana is a writer and has to acquiesce to the demands of his publisher. Sadly, that most often means submitting your manuscript in Word. It makes perfect sense for the publisher. They can have a single file for the entire production pipeline. They don’t have to deal with paper, can easily track editorial suggestions and the author’s reaction to them, and when everybody is happy, they can send it to the printer.

To those with any sense of aesthetics or writing efficiency, it makes no sense at all. Word is a horror and makes me want to stick a pencil in my eye every time I have to use it. Fortunately, there’s an escape hatch. You can write in Org mode and leverage the power of Emacs and then export it to Word when you’re done.

Of course, the actual process can be a little more complicated. Maiorana has an excellent post on how to actually handle the process. The first, probably most important, issue is dealing with different Word formats that the various publishers require. Maiorana shows how to deal with that and to pick the appropriate publisher format template at export time.

Take a look at Maiorana’s post for the details. He also has an interesting clip of a chat between Lex Fridman and Neal Stephenson talking about Emacs. Stephenson talks about publishers “putting their foot down” and requiring Word. He talks a bit about how he deals with that. I’m not sure when the talk took place but at the time Stephenson wasn’t using Org. That’s too bad because it would have solved a lot of his problems. I’m sure he’s probably discovered it by now.

Here at the Irreal bunker, we’re stodgy, like things the way they are, and are not inclined to change things willy-nilly. As far as Emacs is concerned, that manifests itself in the eschewing of themes. The bunker doesn’t really have a theme. It’s just the default light configuration with the background changed to a light tan (oldlace) and the cursor colored red. That’s just a couple of init.el statements; not a proper theme.

Still, lots of people like to experiment with different themes and change them often. That’s understandable—at least if you’re not stodgy—because there are a lot of great themes available and more are being released all the time.

That brings up the problem of changing themes. It turns out that when you load a new theme, it overlays the existing theme and unpleasant interactions can occur. The proper way to handle this is to first disable the old theme and then load the new theme.

Bozhidar Batsov likes playing with new themes but finds that it’s a chore to worry about disabling existing themes. So, being Batsov, he solved that problem by writing a bit of Elisp for loading a new theme that first disabled any existing themes. It’s short and easy and if you also like to experiment with different themes, it might be worth your while to take a look at Batsov’s solution.

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.