Irreal

Kris Brandow has a (very) short video—I think it’s part of a podcast—advancing the idea that you should learn Vim or Emacs. Irreal, of course, is not going to argue with that but I wish he’d given more reasons why you should. What he does say is that you’ll discover you can be more productive with Vim or Emacs than you can with an IDE but doesn’t explain why that is. You should, he says, just try them.

One of the other people on the video objected that you don’t “just try” Emacs. It’s a commitment that takes dedication and effort to learn. That is certainly true of Emacs as we all know but it’s true of Vim as well. It’s not as hard to master as Emacs but there’s a surprising amount to know before you can consider yourself to have mastered it. That’s the problem with saying, “Just try it.” You won’t see real benefits from either editor until you’ve put a some time and effort into learning them.

The most depressing thing about the video is that Brandow described his suggestion as an “unpopular opinion”. I suppose that it might be unpopular among a certain segment of our community but there are also those who think that Javascript is a great, well thought out programming language. Ours is nothing if not a vibrant community with a diversity of opinion.

Álvaro Ramírez has a very revealing post about the compounding benefits of learning a bit of Elisp. Studying how Emacs works and learning its various features pays huge dividends but, says Ramírez, learning some Elisp can compound those dividends and enable you to mold Emacs to a tool hyperspecialized to your needs.

He starts by postulating two features that you realize would be even more useful if you could somehow combine them. Then he gives a specific example. He considers the two packages symbol-overlay and multiple-cursors. The symbol-overlay package highlights all occurrences of the symbol under point in the current buffer and, of course, multiple-cursors lets you perform the same operation in multiple places at the same time.

He uses them both all the time but realized that it would be very handy if he could invoke multiple-cursors with a cursor on each occurrence of the symbol under point. He needed, in short, to combine the action of symbol-overlay and multiple-cursors.

That turns out to be fairly easy if you know some Elisp. Ramírez walks us through how he figured out how to do it and shows the Elisp that does it. There’s not a lot of code (about 20 lines), it’s easy to understand, and it serves as a great example of how a bit of Elisp can work magic. Finally, he made an animated GIF that shows it in action.

This is a nice post and it provides some code that you may find useful for your own workflow. Take a few minutes to give it a look.

Charles Choi has another great addition to his Casual Suite. This time it’s an interface to the re-builder command. There are two things that everyone agrees about Emacs regular expressions:

1. They’re very powerful and useful
2. They have an arcane syntax and are hard to use

Well really, they’re not that much different from other RE syntaxes but there is enough difference to make using them harder than it should be. Indeed, many folks who everyone would agree are master Emacs users constantly bemoan the RE syntax and wish it were replaced with something else such as Perl Compatible REs.

Happily, there’s a tool, re-builder, that can help. I’ve written about it here and here. Unhappily, I find it really hard to use. Finding a good regexp is easy enough but it’s hard to remember how to export that regexp for use in your code or the current command.

That’s where Choi’s Casual RE-builder comes in. Like other members of the Casual Suite, when you need to remember some of the arcane commands, you can simply invoke a handy transient menu to remind you.

As much as I like re-builder, I almost never use it because I can never remember how to export the resulting regexp to where I need it. Choi’s RE-builder solves this problem and, to my mind, increases the utility of re-builder a great deal.

If you have troubles with Emacs regexs or have found re-builder too hard to use, you should take a look at Choi’s RE-builder app.

Just a quickie from something that I’ve had in the queue for a while. Chris Maiorana has a short post on relative line numbers. The idea is that the current line—the line you’re on—is considered line 0 and the lines above and below it are labeled as the number of lines away from the current line.

That’s handy if you’re interested in, say, 5 lines above or below the current line because they’re labeled as that. I love the idea but, truth to tell, I have never found a compelling use case for them. Maiorana says it handy for authors who want to know how many lines there are in the current paragraph but offers no other reason to adopt them.

Still, lots of people seem to like them and they’re certainly easy to turn on. Take a look at Maiorana’s post for the details.

Over at DyerDwelling there’s another nice example of using a transient menu to capture the keystrokes for a set of packages. This time it’s for some spelling related packages. The author couldn’t make up his mind on what keystrokes he wanted for the various commands so he decided to implement a menu instead.

If you’ve been reading Irreal lately, you know that I’m a big fan of this approach, especially as realized by Charles Chou’s Casual Suite. Nonetheless, I’m not sure that a menu is the best solution here. At least not for commands that do things like correct the last misspelling. I use commands like that constantly and want them instantly available without having to wade through a menu.

Still, we can have it both ways. There’s no reason to restrict yourself to one approach. You can have a menu as described in the DyerDwelling post and still specify keybindings for the commands you use all the time. And to be fair, you can also think of the sequence to invoke the menu and the option choice as a single, slightly longer, key sequence.

I’m again impressed at how easy it is to set up a transient menu. Take a look at the code in the DyerDwelling post to see for yourself.

Over at the Emacs subreddit, Ok-Machine-6265 is a new(ish) Emacs user who has some thoughts after using Emacs for about a year and a half. His experience has been good. He loves the power that Emacs gives him and lists some of its many benefits:

• Configurability
• Visibility into all aspects of Emacs’ code and data
• Keyboard centricity: no mouse required
• Stability: core functions just work

and finally, Emacs is an editor for hackers and those who want to make it their own. You don’t have to customize it, of course, but if you need special operations, Emacs makes it possible and easy to add then.

As usual, a lot of the wisdom is in the comments. Ok-Machine-6265 had a few complaints:

• Emacs can be slow to load large files
• There are so many commands that it’s easy to forget their key bindings.

The commenters suggest many solutions to these problems. For example, the wonderful which-key goes a long way in helping you remember key sequences. It’s a third part app that I’ve been using for a long time but, happily, it will be builtin as of Emacs 30.

One of the things that Ok-Machine-6265 says is that Emacs is 100% configurable and one of the commenters objected to that saying that, for example, changing the behavior of Meta in Org mode is apt to break things. The commenters responded, and I agree, that 100% compatibility is not the same as easily reconfiguarable. It may be easy or it may be hard but at the end of the day, almost everything in Emacs is configurable.

Álvaro Ramírez has a very nice post about improving the edebug dislay. He starts be recalling the now nearly 10 year old post from Artur Malabarba on why you should learn to use edebug, the source level Elisp debugger. He says he uses it all the time when he wants to tweak some Emacs behavior.

Edebug will, among other things, let you step through a function and display the results of each expression to the minibuffer. That’s really handy but Ramírez finds it jarring to have to repeatedly move his eyes from the code buffer to the minibuffer. Being Ramírez, he decided to do something about it.

The TL;DR is that he advised the function that displays the value so that the result is displayed on the current line. You can see what that looks like from the animated GIFs on his post. It does seem like a much smoother result and I hope he submits a version upstream as a permanent change.

The big takeaway for me, though, is his account of how he tracked down the appropriate code to advise. If you want to tweak Emacs to do things your way, being able to find the code that needs tweaking is a prerequisite. You can learn a lot about how to do that from Ramírez’s post.

The post is definitely worth a few minutes of your time even if you don’t care about how edebug displays its results. It’s a great example of how it’s not that hard to track down the code that needs your attention.

Charles Choi is back with a new member of his Casual suite. His Casual suite, in case you don’t know, is a collection of transient based menus to make dealing with Emacs major modes and subsystems easier. Choi’s latest addition is for the ibuffer major mode. If you’re like me, you know exactly two commands for this. The first is to change to a named buffer (Ctrl+x b) and the second is to bring up a list of all the active buffers (Ctrl+x Ctrl+b).

Once you have the list of buffers (the ibuffer list), you’re probably aware that you can do some operations on it but, again if you’re like me, you know only a couple of them. One of the things I learned from Choi’s post is that are an astounding 132 commands available in the ibuffer listing. Who knew.

With that many commands, there’s virtually no chance of remembering them all. That’s where Casual Ibuffer comes in. As with the other Casual apps, it doesn’t try to cover every single command but provide easy access to those you’re most likely to use.

As I said, I always thought of the ibuffer list as simply a list and had no idea of all the hidden functionality hiding in it. Just reading through Choi’s announcement will show you how wrong that idea is. The real value, though, is opening our—or at least my—eyes to a whole new set of powerful commands for dealing with buffers, which are, after all, the fundamental Emacs construct.