Irreal

I recently wrote about Casual RE Builder, one of Charles Choi’s Casual Suite apps. As I wrote then, it goes a long ways towards making RE-builder usable for those of us who can’t remember all the commands necessary to export the resulting regex to a useful place.

While he was working on Casual RE-builder, Choi discovered that sometimes—usually in the Dired subsystem—Emacs expects “grep-like” regular expressions rather than the Emacs style. This is undoubtedly because Emacs outsources certain tasks to external grep routines. The fact that the particular regexp subset used depends on what flavor of grep you have installed makes things even more complicated. If you’re like me, all of this is news to you. Somehow, I’ve managed to stumble through using Dired without realizing that it was pulling a bait-and-switch on me.

Regardless, Choi has come to the rescue. He’s changed Casual RE-builder to add an option to export the regexps from RE-builder in grep format. It’s a small thing but it makes Casual RE-builder even more useful.

I’ve already installed Casual RE-builder and presumably I’ll get Choi’s latest changes with my next update. This is, I say again, a really useful package and if you use regexps at all in Emacs, you should take a look at it.

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.