Irreal

Most experienced Emacsers recognize the futility of proselytizing for our favorite editor. Basically, no one but the already convinced want to hear about it. They’re sure the bling, menus, and mouse actions offered by those other editors are superior to an editor that’s older than most of them. But they lack something we have: experience with both their chosen editor and Emacs.

My own proselytizing is mostly confined to Irreal. I very rarely try to convince people one-on-one anymore. Of course, Irreal readers are mostly Emacs users so I’m largely preaching to the choir. Still, we do what we can do.

Gene Goykhman over at Flaky Goodness has a similar story. One thing I liked about his post is that he quotes Prot on the compounding benefits of learning Emacs. Yes, there is a learning curve and it’s (relatively) difficult for beginners to get going but before too long the compounding sets in and, as Prot says, we start to get more out of studying Emacs than we put in.

Of course, we can’t tell anyone this because they don’t want to hear it.

Explaining Emacs to non-users is challenging. A first order explanation is that it’s a text editor but as we all know that’s a pitifully inadequate explanation. As you’re all aware, my default explanation is that it’s a light-weight Lisp Machine but that’s probably not very useful to anyone who doesn’t already know the answer.

Over at The Art Of Not Asking Why JTR attempts to give a simpler answer to the question. For him, as for most of us, the defining characteristic is Emacs’ configurability. JTR uses the metaphor of a coffee maker that not only brews your coffee but makes toast just the way you like it, orders coffee from your favorite roaster, and loads a crossword puzzle tailored specifically for you onto your smartphone. That’s Emacs. It does just what you want in just the way you want to do it.

With Emacs, your code becomes part of Emacs, virtually indistinguishable from the code that comes with the distribution. That means you have almost complete control over what Emacs does and how it does it. It’s hard to think of any other piece of software for which that’s true.

We all have our Emacs story and why we love it and JTR’s is a nice example of the genre. Probably no one but JTR will be completely satisfied with his story because, as I say, we all have our own.

As most of you know, I’m a huge fan of Elfeed and, of course, Org mode. I use Elfeed to read my feed and I do all my writing and note taking in Org mode. It’s natural, therefore, that I’d want a way of capturing Org links to the Elfeed content. You can sort of do that by killing the current content URL to the kill ring and then yanking the link into some other document. That works but it’s not as convenient as simply calling org-store-link and inserting the link with org-insert-link because the saved link doesn’t live in the kill ring and use using the Org functions will automatically format the links in Org format.

Jeremy Friesen decided to do something about this. He wrote a surprisingly simple function that allows you to call org-store-link directly from within Elfeed. The generated link will be to the target URL not the RSS entry so it’s ideal for generating a link to the actual content.

If you use Elfeed to collect and curate interesting content and often—or even sometimes—want to save a link to the content in an Org file, Friesen’s solution is just what you need. The post is short and the code is minimal so you should definitely take a look.

Over at the Emacs subreddit, kosakgroove has just learned about Emacs registers and considers it a game changer. His post is little more than a headline so all the action is in the comments. Surprisingly—at least to me—many of the commenters were unaware that registers even existed.

For me, registers are useful in two situations:

1. I want to save my current window configuration so that I can run some function—eshell, for example—in full screen, and reinstate my previous window configuration when I’m done.
2. Saving values or counters in keyboard macros.

For example, here’s how I run eshell:

(global-set-key (kbd "H-e")
                (lambda (exit)
                  "Bring up a full-screen eshell or restore previous config.
With a prefix argument, exit eshell before restoring previous config."
                  (interactive "P")
                  (if (string= "eshell-mode" major-mode)
                      (progn
                        (when exit
                          (insert "exit")
                          (eshell-send-input))
                        (jump-to-register :eshell-fullscreen))
                    (progn
                      (window-configuration-to-register :eshell-fullscreen)
                      (eshell)
                      (delete-other-windows)))))

The important thing to notice in this example is the use of :eshell-fullscreen as the register key. That’s a trick I learned from Magnar Sveen. In interactive use, the key has to be a single character but because of an implementation artifact, any symbol will do from within Elisp. That’s nice because you don’t have to worry about having a user write something over your saved window configuration. I use this same trick a lot in my init.el.

Here’s an example of using a counter register in a keyboard macro. Both of these example are a bit specialized. You can simply save some text or a position in a register and insert it later when needed. Registers really are an almost magical power and it pays to get familiar with them.

Marcin Borkowski (mbork) has a really great post about arranging for certain commands to prompt for verification before executing. Usually, those prompts are simply annoying but sometimes they’re actually useful. For example, you can arrange for Emacs to ask you for confirmation before exiting. Normally that would be really annoying but after I accidentally exited Emacs several times by fat fingering some shortcut, I began to appreciate its usefulness.

Some, dangerous, commands always prompt for approval. Others, like kill-emacs don’t ask for approval by default but can be configured to do so to help those like me who are prone to fat fingering. But, of course, most commands don’t ask for confirmation and don’t have a configuration option to enable it.

Mbork gives an example of a command where he wanted approval before it executed. I have another: Several times I fat fingered the command to print the current buffer—which always seemed to send my printer into a schizophrenic fit—and finally decided to do something about it. But what?

Mbork has two suggestions. He first thought about advising the function he wanted to protect—that’s what I did with print buffer—but then it occurred to him there was a builtin solution. He realized that he could simply mark the function in question as disabled and Emacs would automatically prompt before executing it. Even better, you can also specify what the prompt will be.

But wait! There’s more. While researching that solution he discovered the command command-query that does exactly what he wanted. You can check out his post for the details but the TL;DR is that if you want a prompt before executing a given command, command-query is the solution.