Irreal

One of the nice things about Emacs is that when you find yourself performing the same set of steps repeatedly, it’s easy to capture those steps into an Emacs function or even a keyboard macro. If you’re like me, you’ll keep repeating those steps over and over until one day you realize that you really should automate them. Álvaro Ramírez has a video showing a nice example of this: cloning a git repository.

Ramírez begins his video by showing his old procedure. It’s really simple. Capture the URL to the clipboard, change into the target directory, paste the URL into a git clone command on the Eshell command line, execute it, and open the directory in Dired. If there’s a README, open it as the last step. It takes longer to write it down than it does to actually do it.

Still, they’re simple steps and easy to automate, which is what Ramírez did. His solution is nice. He just has to capture the URL and call his function. Everything else, including opening the README file is handled automatically. He has a bit of code to allow choosing the target directory if he doesn’t want to use the current directory. You can check out his code in his GitHub repository. It is, as I say, simple but it’s a nice example of removing friction from your workflow: just let Emacs handle the routine chores.

The video is only 6 minutes, 54 seconds long so you should have no problem finding time for it. It’s interesting and worth a few minutes of your time.

If you’ve been around Irreal for a while you know that we here in the Irreal bunker have never felt the need for a starter kit. A lot of that is probably due to the fact that they weren’t generally available when I moved to Emacs. I just started with an empty config and began adding things—sensible scrolling, C indentation, and a couple of other necessities—right off the bat. Other changes and additions came later.

Those initial changes are instructive. There were, of course, reasonable defaults for all of them, they just weren’t what I wanted and that’s also the problem with starter kits: they have their own idea of the right thing and it may differ from yours.

Still, when you’re starting out it’s nice to have a way of establishing a reasonable initial Emacs environment even if it’s not exactly what you want. If you do that, it’s important, I think, that the starter kit be easily modifiable. A nice example of this is medicated-emacs, a minimal configuration that’s easily adaptable. Take a look. It mostly set’s a few configuration variables and loads a few select packages.

You probably won’t agree with all these choices. I certainly don’t but the thing is, they’re easy to change. The configuration variables were set with the custom package so they’re easy to change if you want to. You may not want all the packages medicated-emacs loads. For instance, I have no need for rust-mode but it doesn’t hurt to have them there in the short term and after you learn a little more about what you’re doing, you can simply remove the package from the config.

If you’re a beginner and think a simple, non-opinionated configuration would be helpful, take a look at medicated-emacs. It will get you going and will be easy to adapt to your evolving needs.

As many of you know, your can output to a buffer directly from within Eshell by redirecting the output to a #<buffer ...> structure like this

Welcome to the Emacs shell

~/org/blog $ echo "Hello World!" > #<buffer hello-buffer>

That naming convention may seem weird but it’s exactly how Emacs refers to buffers. As Christian Tietze says in this post about redirecting output to a buffer you can see this by executing the current-buffer command (it’s not an interactive function so you have to call it as (current-buffer) in some Elisp context).

Tietze covers all this in his post but the interesting thing is that he hates having to remember and type the #<buffer ...> structure. I can sympathize. I got it wrong at least once while preparing this post. Tietze has the solution. He wrote a function, new-buffer, that generates a temporary buffer and returns it just as if you had specified it with the buffer notation. Then he can write Hello World! into a temporary buffer like this

Welcome to the Emacs shell

~/org/blog $ echo "Hello World!" > (new-buffer)

That’s a bit easier to remember and less clumsy to type than the #<buffer ...> construct.

Of course, as Tietze says, all this makes sense only if you’re already in Eshell. Otherwise, you can achieve the same result by simply using shell-command or async-shell-command. Regardless, Tietze’s post is interesting and worth a couple minutes of your time.

Álvaro Ramírez is back with the second video in his new series. This video is about making some simple UI adjustments to Emacs to bend it into looking and acting in a way meets your needs. That doesn’t sound too exciting except that Ramírez shows all this by doing something that many of us will find useful: He starts a separate Emacs instance and arranges for the changes he specifies in the first instance to appear in the second instance.

That’s actually easier than it seems. Starting the second instance is just a matter of calling Emacs with some command line arguments to specify where to find init.el and where to put temporary Emacs variables, such as the lock files and socket pointers. If you need to invoke independent instances of Emacs, it’s probably worthwhile capturing the command into an Emacs function or shell script.

Arranging for commands to take place in the second instance is also easier than you might think. For that Ramírez defines a macro that takes the command as an argument and makes a call to the other instance via emacsclient asking it to execute the command. If that sounds mysterious, take a look at the code. It’s straightforward and easy to understand.

Looking at the code for all these snippets is easy because Ramírez has it all in a blog entry. You can capture the code for invoking another Emacs instance and the macro for sending commands to it and use them in your own work.

The particular customizations that Ramírez makes are beside the point. They’re what works for him and even if you want to steal some of them, your ideal Emacs UI almost certainly differs. The real value of his video, I think, is that it shows you an easy way to set up an environment to try prospective changes.

The video is 14 minutes, 37 seconds so it should be reasonably easy to fit into your schedule. It’s definitely worth 15 minutes of your time.