Irreal

Ag Ibragimov had a problem that many of us have experienced. He learned a term from a video but later couldn’t recall the term. We went back to the video to search for it but couldn’t find it. What to do?

Ibragimov realized that he was working too hard and that what he really needed to do was capture the close captioning from the video. This was meant to be a one-off to solve a specific problem so he didn’t do anything fancy. He used youtube-dl to grab the video and wrote a bit of Elisp to extract the actual text.

After a while he realized that it was generally useful and bundled everything up into an Emacs package. Since then he’s added timestamps to the output. He’s not yet pushed it to Melpa but perhaps that will come later when he feels the package has stabilized.

This package, like many, resulted from a small itch that Ibragimov scratched by leveraging an existing command line app and writing some Elisp to process the data that it retrieves. It was later that he realized that he could use it again for other videos and that it might be useful to others too. It’s something to remember when you consider whether it’s worth writing some code for a task that you could do manually. Maybe you can’t amortize your time with a single use but it’s also possible that you and others will find it generally useful.

I recently came across a truly awful post to the Emacs subreddit. It wasn’t the post itself; it’s what it revealed. The post asked how to counter FUD from users of the bling-centric editors that Emacs was old technology that couldn’t hope to compete with “modern” editors such as VS Code and Jetbrains. There’s nothing wrong with that, of course. As keepers of the faith, it’s our duty to counter and shutdown that nonsense whenever it raises its head.

Rather, it was the backstory that was disturbing. The story is about his old company and a friend who is still there. That company has recently decreed that all developers have to use VS Code: it’s the new company standard.

There’s nothing wrong with VS Code, of course, although users may want to think twice before committing. The problem is telling developers they have to use VS Code. Can you imagine trying to tell a surgeon they had to use a certain brand of scalpel? You’d be told to go pound sound before you could draw your next breath.

I’ve told the story before about the clueless technical manager who proposed such a mandate at a company I once worked at. I and the other senior developer were able to explain the facts of life and aborted the disaster before it occurred. As you all know, we here at the Irreal bunker are all in on Emacs but we believe that choosing an editor is like choosing a mate: others may disagree with your choice but it’s none of their business. More succinctly: choose whatever editor works best for you. Everyone else should butt out.

Mandates like this are always imposed by people who don’t actually do development. They imagine they’re encouraging a shared development culture but what they’re actually encouraging is a mass exodus. I don’t know about you but I’d be out the door in an instant if some suit presumed to tell me what editor to use.

Somewhere in 2014–2015, I came across James Somers’ beautiful article on Webster’s 1913 dictionary and why it’s the right choice. It was a revelation to me, opening my eyes to a wonderful resource that ever since has helped me find just the right word when I’m writing. I loved the article and even put it in my “blog ideas” queue although I felt that it wasn’t something most Irreal readers would care about.

In that, as in so many other things, I was completely wrong. In 2015, I finally found a hook for the post—DuckDuckGo bang shortcuts—and published Draft #4 about it. That article and the others in the series have, judging by engagement, turned out the be arguably the most popular posts in the Irreal corpus.

It probably seems strange have a series of articles on this subject but it was necessitated by the disappearance of the dictionary from the University of Chicago website and a desire to make it available from within Emacs. Somers’ article itself has proved to be tremendously popular—Somers says it has been read over 130,000 times—and people are constantly discovering and commenting on it. There always seems to be something new to report about it.

The latest thing was something I’ve just discovered: As of Emacs 28.1 you can access Websters 1913 from within Emacs without loading any packages or data. That’s really great because it means, essentially, you get the dictionary for free. The above post gives you the TL;DR on how to do that.

There turns out to be more to the story and, of course, Mickey over at Mastering Emacs has all the details. The new Emacs capabilities depend on a client/server protocol for dictionary lookups that Emacs implements in dictionary.el. There are more capabilities than the dictionary-search function that I wrote about. There are also some navigation shortcuts to make moving around easier. If you prefer local copies of your dictionaries, you can arrange to run a server on your own machine. Take a look at Mickey’s post for all the details. The short story is there’s a lot more to dictionary.el than I thought.

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.