Irreal

Guangwang Huang, over at whatacold’s space, has a useful post on debugging Emacs. It’s aimed at beginners but will be useful for more experienced Emacsers too. The basic idea is what you should do when you start Emacs and get an error. This most often happens after you upgrade a package and can be hard to deal with.

The first thing to do, of course, is to start a clean invocation of Emacs. The easy way to do that is with emacs -Q. That gives you a “clean” copy of Emacs without any of your configuration or packages. Of course, the problem probably lies in a package so you want a clean Emacs but with that suspect package loaded too. The first step is to determine the offending package. Starting Emacs with emacs --debug-init will help you find the proper package and then you need to start a clean Emacs with just that package loaded. Huang shows how to do that. At this point you can start drilling down to find the actual problem.

The main way to do that is to tell Emacs to drop you into the debugger and give you a backtrace when an error occurs. There are several events you can use to trigger this including, even, the output of a message that matches a regular expression. Take a look at Huang’s post for the details.

There’s nothing particularly advanced about Huang’s post but it provides just the information you need to solve many of the problems you encounter with Emacs. It’s reasonably short so there’s no reason you shouldn’t a couple of minutes reading it.

Mahmoud Mazouz is an Emacs n00b. He’s been using Emacs for about two months but has experience with (neo)Vim and VS Code. He recently posted his view of Emacs and what he sees as its strengths.

Like many (or, perhaps, most) of us, he finds the chief benefit to be Emacs’ extensibility. Unlike many folks, Mazouz is happy enough with Emacs functionality; it’s the look and feel that he was unhappy with.

That’s a common complaint—especially among n00bs—but instead of taking to Twitter to complain about it, Mazouz decided to fix the UI/UX to suit his needs. He found it reasonably easy. Rather than use someone else’s theme, he built is own. Similarly, he tried several keybinding schemes before settling on Meow.

He also didn’t like the mode line but found that it was too complex for him to fix. Fortunately, he liked the Doom modeline, which is available as a standalone package on MELPA, and is happy with that.

One of the themes of the post is that it’s possible to do a lot of Emacs customization even if you aren’t experienced in Elisp. Most of the functionality that you want that doesn’t come with stock Emacs is available as packages. Mazouz mentions Org-mode (although that’s arguably a stock feature now) and Magit. Pretty much any functionality you might need is available as a package.

There’s nothing surprising in Mazouz’s post for experienced Emacs users but I like the way he fixed the UI/UX to suit himself. Worth a read if you also like such stories.

When you think about it, the title of this post doesn’t appear to make sense. Yasnippet is a template system for adding customized boiler plate to an Emacs buffer. It’s raison d’être is to enable shortcuts for various programming constructs such as the C for loop.

Still, it’s a flexible system so it finds all sorts of uses. If you’re writing in LaTeX, it can help with things like the environment boilerplate. Similarly, it’s great for things like blog headers.

Erik L. Arneson has a post that describes how he uses Yasnippet for his writing. After explaining how to install Yasnippet, Arneson describes his uses. That turns out to be mostly things like blog headers and Org headers for certain other structured files. You can read his post for the details.

My personal use is almost entirely things like that. I never think to use it when I’m programming even though I do have the appropriate snippets loaded so the snippets I use are mostly for prose and various record keeping applications where the snippet provides a sort of form that I can easily fill out by tabbing through the fields.

The takeaway is that technology like Yasnippet doesn’t have a lot of application for writing prose except for headers and other boilerplate and perhaps for markup if you’re using something like LaTeX. Still, even those seemingly minimal applications can save a lot of time.

I just ran across a video on the birth of Emacs from last year. It’s by Lars Brinkhoff, Irreal’s go to guy for questions on the history of Emacs. As I’ve written before, he maintains a repository of historical Emacs code all the way back to TECO.

The video is a series of demonstrations of some of that ancient code. It starts with showing what a pain it was to use TECO. It did, however, have a macro language that was fairly capable and Emacs famously began life as a set of macros for TECO. It’s where the name Emacs comes from: Editing MACroS. It was a sort of compilation of the TECO macros that individual users at MIT’s AI labs had written. The idea was that then everyone would be working in the same environment.

Since Emacs was originally written as TECO macros, it wasn’t very portable so it was rewritten in various languages such as LISP and C. The video gives a demonstration of some of those old systems. If nothing else, watching them will show you how good we have it now.

Now, of course, Emacs is synonymous with GNU Emacs, which is available on essentially any platform that matters. Brinkhoff tells a nice story. What began as a way of letting hackers share someone else’s TECO session has blossomed into what many of us consider the world’s best editor. Not everyone agrees with that last assessment but none but the ignorant doubt that it’s certainly a contender.

The video is about 41 and a half minutes long so you’ll need to schedule some time. If you’re interested in old Emacs implementations and how things used to be, take a look at the video.

Torstein Johansen has an interesting video on using Emacs as an IDE for shell programming—especially Bash shell programming. We, or at least I, don’t usually think of shell programming as requiring an IDE but as Johansen shows, a bit of Emacs configuration can significantly ease the task.

He starts off with sh-mode and shows how to adjust the indentation. That gives you syntax highlighting and automatic indentation. Add autocompletion (with Hippie Expand) to help with entering code and navigation (mostly with Projectile) to make finding functions—even if they’re in a different file—easy and you’ve got a good basic Emacs setup for working on shell files but Johansen doesn’t stop there.

He adds LSP and flycheck-mode for advanced navigation and code linting. He shows how to run your script right from Emacs and even how to output an execution trace. He also shows how to run unit tests and perform debugging. Those require adding separate packages and binaries, of course, but if you do a lot of shell programming it’s well worth the effort and space on your system.

Finally, he covers some of the yasnippets that he uses and gives a quick demonstration of git-change-markers. Neither is particular to shell scripts, of course, but they can be useful.

Again, if you regularly work with shell scripts, this video is worth your time. It’s about 18 and a quarter minutes so plan accordingly.

WEATHER UPDATE [2022-09-28 Wed 14:03]: Ian came ashore near Ft. Myers (about 100 miles south of Tampa). Lots of flooding there but things in Tampa are still calm except for moderate, continuous rain. We’re still expecting strong winds and lots more rain as Ian moves up the peninsula.