Irreal

Marcin Borkowski (mbork) has a short post on how to make y-or-n-p return t when the user types Return. Check his post for the details but the TL;DR is that he temporarily extends the y-or-n-p keymap to have Return return as if y had been pressed.

It’s a fairly unique requirement but his approach works for other use cases where we want to add or change a key to an existing keymap. If you have such a need, take a look at mbork’s post.

As an aside, I should mention that mbork’s new book is finished and available. I read a draft of his early chapters and thought it was well done. Take a look if you’re interested in Emacs books.

If you’re like me, you hate dealing with text outside of Emacs. Even those of us who spend as much time as we can inside Emacs have to interact with other applications. In my case, that’s mostly Safari. The problem with Safari is that its architecture doesn’t allow extensions that will call Emacs to edit text fields the way, say, Firefox does.

MacOS, of course, recognizes many of the Emacs keybindings but you can do much better. For many years, I’ve used the operating system’s ability to assign keys to editing functions to install a fairly comprehensive set of Emacs editing keybindings but while that helps with muscle memory, it’s not really like editing with Emacs. I’ve long wished for a way of popping into Emacs to edit the text fields from other apps.

Now, happily, my wish has been answered. Take a look at this video by dmgerman that demonstrates his Edit with emacs Everywhere package. It provides just what you’d want: if you’re in any text field in any Mac application, you can press a key sequence to put up an Emacs buffer in which you can edit the text in the field and then return the edited text to the calling app. The important thing here is that you’re not just using Emacs keybindings but using Emacs itself with all its power. Perfect!

The package depends on Hammerspoon to mediate with the OS. It’s easy to install and, of course, is more generally useful but even if it weren’t, giving us the ability to edit all text fields with Emacs is worth the price of admission.

If you use the Ivy/Swiper/Counsel package, you know that are a lot of ways to do searches. So many that it can hard to remember what they all are and how to invoke them. Fortunately, Yuri Tricys has come to the rescue with a hydra for searching.

Tricys is planning some follow on posts that describe a few of the functions and packages that his hydra uses. He also has a separate section for some programs to use in the Windows environment.

It’s worth taking look at his hydra if only to get some ideas for the searches you may want to make. I agree with Tricys that hydras are the ideal solution for this sort of thing. They’re easy to implement even for someone who doesn’t know Elisp. That makes them a great way for any user to create and manage their own menuing system. There’s extensive documentation for hydras at the package’s Git repository so they’re accessible to everyone.

Derek Taylor has a video that calls out what he says are Three HUGE Mistakes New Emacs Users Make. He says that many Emacs n00bs have a hard time getting started because they make the same three basic mistakes.

The first mistake they make, he says, is treating Emacs like Vim or other editors and starting it for each file they want to edit. This is one of the first things someone moving to Emacs learns. You have to modify the way you do things. What I and many others do is start Emacs when I first login and just keep it running for the whole session. As a practical matter, that’s until I reboot the system or restart Emacs because of package updates. Taylor recommends starting Emacs in daemon mode and calling emacsclient when you want to edit a file. That’s okay but not as efficient for my workflow, especially since I do almost everything from within Emacs. In either case, you avoid the relatively long—compared to other editors—startup time.

The second mistake is using some sort of file manager to choose a file to edit. Emacs, of course, has Dired that does this and more. There’s no reason to use a separate application for file browsing especially since it leaves an unneeded application running and taking up screen real estate.

Taylor’s last piece of advice is the most controversial. He says that you shouldn’t run Emacs in terminal mode unless you’re running on a system without a GUI windowing system. Some people have very strong feelings on this question: they’re either all in for running the GUI version of Emacs or they insist that real programmers stick to terminal mode. Although I almost always run Emacs in GUI mode—because of the extra capabilities you get—I’m pretty much agnostic on the issue. I do think that the GUI offers enough benefits that you should use it in most cases but it doesn’t bother me when other folks choose to run in the terminal.

It’s an interesting video. If you’d like to watch, it’s just short of 13 and a half minutes so it should be easy to fit in.

One of the things you often want to know is what keybindings are available for the current buffer. Emacs, of course, has a command for that: describe-bindings, bound to Ctrl+h b. I never use it.

The problem is that it outputs too much garbage in an unhelpful way. Lars Ingebrigtsen has noticed this too an decided to do something about it. Part of the problem is that the original code was written in C making it hard for many to work on. Happily, it’s recently been refactored in Elisp so changes are easier. Ingebrigtsen took advantage of that to prettify the output and put the relevant information at the top.

In Ingebrigtsen’s post you can see side-by-side comparisons of the old versus Ingebrigtsen’s updated version. The best news is that the changes are already on trunk in the Git Emacs repository so we should be seeing them soon.

The describe-bindings function has been in Emacs for a long time without much change but now it’s been significantly revised. This story—and many others like it—put the lie to the ignorant assertions on social media that Emacs is old and dead. It may be old, for software, but it’s far from dead. Indeed, even ancient and relatively unimportant parts of it are candidates for improvement.

And, of course, thanks to Ingebrigtsen for bringing us this improvement.