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.

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.