Irreal

Mickey from Mastering Emacs has posted an excellent summary of shells & emulators in Emacs. The subject can be a little confusing—mostly centering around the difference between a shell and an emulator—so if you’ve ever been uncertain if you should be running shell, term, or ansi-term be sure to check out his post.

If you’ve used any of those you know that they all have limitations. Mickey’s post tells you how to work around some of those limitations and how to do things like change the default shell or stop the duplicate echoing of shell input. He also discusses Vterm and Eshell.

Mickey’s first recommendation is to consider whether you need a shell at all. Emacs, after all, has Dired for file manipulation, Magit for Git interaction, built-in network utilities, and the compile function to compile and test your code. Even as a long time command line guy, I’ve found that I rarely need to invoke a shell these days.

If you do need a shell, Mickey recommends either shell or eshell. These have the advantage that you’re working in an Emacs buffer so you have all the usual Emacs capabilities available for working with the text. I like Vterm because it gives a much better emulation than the others but as Mickey says, you won’t have the valuable Emacs features available for working with the buffer.

Finally, there’s a long list of comments that are also worth reading. Especially Ramin Honary’s comment on using coterm for better terminal emulation. As always with Mickey’s posts, this one is very much worth reading

Just a quickie today. Bytedude wanted to customize his Eshell prompt to add the date/time. With most shells, that’s simply a matter of changing an environment variable but with Eshell it’s a little more complicated.

It turns out the Eshell forms the prompt by calling a function and if you want to change the prompt you have to provide a new function. That’s easy because the function is pointed to by a variable so you need only change the variable to point at your own function. The function itself need merely form the desired string for the prompt.

A slight complication is that Eshell needs to be able to recognize prompts. It does that with a regex so if you change the prompt, you may need to change the regex. Take a look at Bytedude’s post for the details. The Emacs Wiki also has documentation on setting Eshell prompts that is worth taking a look at if you’re interested in customizing your Eshell prompt.

Álvaro Ramírez continues to experiment with his DWIM Shell Command package. The basic idea was that to provide a framework that made it simple to invoke a command that has complex arguments and options directly from Emacs. Ramírez has published a few posts that demonstrates its use and advantages that Irreal has reported on.

Now, Ramírez has realized that sometimes you have a bit of code in some language or another to do some task. If the language can take input from STDIN, there’s no reason that DWIM Shell couldn’t invoke those too. His latest iteration does just that.

It’s a really nice extension to his previous framework. It allows you to define frequently occurring tasks as Emacs functions that invoke the appropriate commands just as if you had entered them from the shell. Ramírez notes that you can, of course, accomplish all this with Elisp but that the DWIM Shell framework provides an easy way of doing it even if you don’t know Elisp.

There’s no news as to whether this code is headed for MELPA or some other repository but it’s a single file and easy to grab if you want to play around with it now. I’m pretty fluent with Elisp so I could always do these things directly but Ramírez’s package provides an easier way to perform these functions.

The incomparable Mickey of Mastering Emacs fame has a really nice post on the power of keyboard macros. Most of us, even experienced Emacs users, tend to think of keyboard macros as a way of automating repetitive text editing but they’re actually much more powerful than that.

The key is that when you’re recording a macro, Emacs records everything you do. Thus, to use one of Mickey’s examples, it’s a simple matter to record your actions while you’re configuring your Emacs window setup and then use that macro whenever you want that particular setup in the future. Of course, to do that you need some way of persisting your keyboard macros across Emacs sessions.

That’s easy to do and Mickey explains the process, including how to turn the keyboard macro into a function that you can call in the normal way with Meta+x macro-name. Mickey also explains how to edit, debug, and step through a keyboard macro.

As Mickey points out at the beginning of his post, Emacs has all sorts of users and many of them don’t know or want to learn Elisp. Still, they, like the rest of us, have tasks they’d like to automate. Rather than having to learn Elisp, a simple keyboard macro will often provide just what’s needed.

All Emacs users should definitely read through Mickey’s post, probably more than once. You might even want to bookmark it so you can easily retrieve the details of working with keyboard macros.