Irreal

Kristoffer Balintona has a nice post on Emacs occur. If you have moderate familiarity with Emacs, you have probably used occur on occasion. I use it all the time but still wasn’t aware of everything it could do.

Happily, Balintona is here to fill in the blanks. The information is all there in the documentation, of course, but it’s easy to miss it when skimming through the doc looking for the information that you need.

The first significant thing is that you can restrict the action of Occur to a specific region of the target buffer. You probably won’t want to do this very often but it’s easy to see how it could be useful. The second significant thing is the number of lines of context.

You can specify how many lines of context before and after the matching regex to include but you can also specify a string in which case what is displayed acts as a replacement string. You certainly won’t need that capability a lot but when you do, it’s perfect.

Take a look at Balintona’s post or the documentation for the details. This is another example of how learning Emacs is a lifelong endeavor. You learn bits and pieces of a certain functionality but later discover that it’s much richer than you believed.

In another in a seemingly unending sequence of such questions, sav-tech, over at the Emacs subreddit asks if Emacs is useful in practical life. I’m not sure what he thinks all we Emacs users are doing if it’s not practical but let’s take his question as being in good faith.

As usual, all the action is in the comments. The main thing that I noticed is that people using VS Code and the like always say that it does what they need right now. That’s because those editors are configured to provide the conventional services. It’s great. There’s no setup required, you just start using it to do what you need to do.

The problem is what comes next. Sooner or later you’re going to need to do something that the VS Code developers didn’t consider and you’re going to be out of luck. With Emacs, you’re also going to find yourself wanting to do something the developers hadn’t anticipated. The difference is that with Emacs you can simply add the capability. Often this doesn’t require anything more than a keyboard macro or some shortcut configurations. If you learn a little Elisp, you can make Emacs do anything you want.

Sav-tech says that someone on Discord told him that Emacs is a monolithic editor, takes only 20–40 minutes to learn, and, anyway everyone is using VS Code now. That’s a fact free statement by someone who has no idea what he’s talking about. Read the comments if you want your faith in the judgment of software engineers restored.

You can use Emacs, VS Code, or whatever works best for you but let’s at least try to keep the discussion informed.

James Cherti has announced a new package, Compile Angel. The idea is to keep all your Elisp files compiled with both the byte compiler and the native compiler. It has modes to compile any outdated “binaries” when a modified Elisp file is saved or when one is loaded. Both compilations are important because byte compilation helps Emacs to load faster while native compilation, of course, help Emacs run faster by generating native hardware code.

In his announcement, Cherti explains how Compile Angel differs from auto-compile. The TL;DR is that Compile Angel is lighter weight and compiles more files than auto-compile.

This seems like a nice package. Strictly speaking, it’s not necessary, of course, but it’s another way reducing the friction of maintaining your Emacs installation. Unless you’re the type of person who enjoys a completely hands-on approach to system maintenance, Compile Angel is probably worth looking into.

The project GitHub repository is here but except for the code is essentially the same as the announcement.

It’s easy to be snarky about management—especially the suits—and Irreal has certainly indulged itself often. In case you think such snark is unwarranted, I offer this sad example for your consideration.

It demonstrates everything that can go wrong when people with no technical skills nevertheless feel inclined—and entitled—to make decisions that aren’t really any of their business and for which they are eminently unqualified. Take a look at their description of Emacs:

“An old fashioned and slow text editor created by Canonical for use with the Ubuntu operating system”.

There’s not a single part of that description that’s correct. You Vim guys can stop laughing now. Here’s the description of Vim:

“Developed by CentOS, an editor with a steep learning curve”.

I guess that’s a slightly better description than the one for Emacs in that “with a steep learning curve” might be said to be accurate. On the other hand, these same suits are happy to embrace Neovim so, again, they have no idea what they’re talking about.

I can’t imagine working for a company that would presume to tell developers what editor they should use let along one that justifies their decisions with such a complete lack of knowledge of what they’re talking about.

All I can say is that if you are working for this company or one like it you should start looking for other employment forthwith. Even if your preferred editor is on the approved list, management’s attitude and presumption will eventually reach out to bite you.

Over at the Emacs subreddit, Available-Inside1426 asks why there isn’t an Emacs 2. By that he means a rewrite of Emacs to address what he sees as problems with Emacs. Those problems include the usual silliness like a better GUI implementation, better mouse support, a client-server architecture, and so on. The only improvement he suggests that makes sense to me is implementing threads.

Of course, everyone would like Emacs to have a robust thread implementation but the problems are legion. Here’s an account of one brave soul’s attempt to implement them. The TL;DR is that in the end he gave up because there’s just too much shared state built into Emacs.

One thing you hear all the time and that Available-Inside1426 repeats is that “Emacs was made for a different world”. I don’t know what that means. Sure, Emacs was made in a different world but I don’t think it’s true that it was made for a different world. After all, it was made to edit text as efficiently as possible and in that it still performs better than any other editor. My cynical suspicion is that what “made for another world” really means is that it doesn’t have enough bling, and is not centered on point and click.

Emacs development is, in fact, proceeding apace and everyone with even a bit of software development experience knows that rewriting a mature system always ends in tears. Emacs doesn’t need to be rewritten. Sure, some things would benefit from improvement but that exact process is always underway. Your pet wish may not be as high on the list as you’d like but if it’s worthwhile, it will certainly be implemented eventually. Who knows? Maybe we’ll even get a good thread model.