Irreal

Brian Zwahr uses ansi-term in Emacs for his shell work but found that there were a few things about it that he didn’t like. Being Emacs, those things were pretty easy to fix and he posted about his fixes.

He begins with a bit of Elisp that kills the ansi-term buffer when the shell exits. This isn’t a huge thing but it is annoying to have the now useless buffer hanging around so this is a worthwhile change.

At the other end, he arranges for ansi-term to automatically use his preferred shell. That way he doesn’t have to specify it every time he starts an ansi-term.

Zwahr noticed that when he pasted something into the buffer with 【Ctrl+y】 the shell didn’t see it. Again, a bit of Elisp fixed that.

Finally, there were a couple of display issues, one involving the solarized color theme, that required tweaking.

I prefer eshell for most of my shell work and just call up iterm2 when I need to do something that eshell doesn’t handle well but if you like the ansi-term solution, you should definitely give Zwahr’s post a read. You may want to grab some of his fixes.

Austin Walker recently gave a talk at the Boston Emacs Meetup on using John Wiegley’s ledger program. Happily, there’s a video of the talk so we can all enjoy it. Ledger is a command line program but, of course, there’s a ledger-mode for Emacs so that you can handle everything from your editor, if you like.

What I like about the program is that everything is plain text. Ledger is merely a parser and report generator so it doesn’t change the data files at all. You can back them up with git or whatever method you use. You can generate them however you like. You can also massage the data with your own scripts in any way you like. Maximum flexibility and no data lock-in.

If you’re in charge of handling your finances and like to keep track of things, ledger seems like an excellent solution. It’s open source, uses plain text, and has an Emacs mode. What’s not to like?

Watch the video and see what you think. It’s 51 minutes, 33 seconds so you’ll need to schedule some time.

For some workflows, especially those centered around the terminal, it makes sense to run Emacs as a server so that you can use emacsclient to quickly pop up an Emacs frame. I mostly just have a GUI instance of Emacs running all the time but it’s convenient when I’m in a terminal—especially on a remote machine—to pop up an Emacs frame right in the terminal rather than switching focus to the GUI Emacs. M. J. Wall has a script that makes that easy.

A GUI Emacs instance is started automatically when my desktop comes up so I initiate the server from my init.el. Other people have different processes and maybe don’t even have a desktop so it’s convenient to be able to start the Emacs server early on so that emacsclient is available whenever it’s needed.

Happily, the Emacs Wiki has us covered with an article on how to run Emacs as a daemon. The idea is that Emacs is started at boot time but as server. The article covers how to do this on various Linux systems and on OS X. It also covers how to shut down the server and how to run separate servers for multiple users. If you want to run Emacs as a daemon, be sure to give this article a read.

Mbork has posted a sequel to his highlighting post that I wrote about before. This time he discusses iedit. Mbork says you can think of it as Hi Lock mode with the added capability of editing all the highlighted entries at once. I usually think of it as an alternative to Magnar Sveen’s multiple cursors.

If you want to see the power of iedit take a look at abo-abo’s refactoring workflow. The basic idea is to use rgrep to find every occurrence of a variable, enable editing of the grep output with wgrep, and then change every occurrence of the variable (in the grep output) with iedit. Abo-abo says that he thinks of iedit as a drop in replacement for occur and query-replace.

As mbork mentions in his post, the selection criteria in iedit are very flexible and require a bit of care. Mostly this is because iedit will place symbol bounds around the current symbol. The easy way to get all matching strings is to just mark the string you want to match.

It also behaves differently when given prefix arguments. You can, for example, restrict its action to the current function or cause it to use the same occurrence as the last time it was used in the current buffer. See the built-in help for the details.

Sean Irby has posted his thoughts on why you should be using helm. Irby argues that helm not only makes navigating the Emacs UI easier but also assists in learning Emacs in much the same way that spelling correctors help you learn correct spelling.

Helm is, at heart, an Elisp programming framework that allows you to easily add UI elements to a project. You can see this in Kris Jenkins’ brilliant video on building a Spotify client. But it also comes with a number of built-in and add-on functions that can be accessed at the user level.

It’s these built-in and other user-level helm extensions that Irby writes about. He mentions the built-in functions

• helm-apropos (apropos with fuzzy matching)
• helm-find-file (ido-like functionality)
• helm-M-x (smex-like functionality)
• helm-google (call google from Emacs)

and the helm-extentions

• helm-dash (use Dash docsets from within Emacs)
• elevator (a REPL for data transformation)
• helm-descbinds (describe currently active bindings)
• helm-proectile (a Helm interface to the Projectile package)

Irby makes a good case for at least giving Helm a try. If you write your own Elisp, Helm can be especially useful but even as a user it offers at lot.

Mbork has another nice post on some of the lessor known corners of Emacs. This time it’s about highlighting words in a buffer. There are lots of ways of doing that, of course, but they have subtle differences that make them suitable for different tasks.

The most common such command is isearch. It’s what most people use all the time for searching or even navigation. As mbork points out, isearch highlights the target word only until you exit the command, which may not be what you need.

The second command is occur. I use this all the time but as mbork says many people are probably not familiar with it. What I didn’t know was that you can edit the original buffer directly from the occur buffer and you can enable a mode where the original buffer will display the line that the point is on in the occur buffer. See mbork’s post for the details.

Finally, there is highlight-regexp, which allows you to highlight any expression matching a regular expression. I’ve only used that command once. I tried it and couldn’t figure out how to turn it off short of killing the buffer. It turns out to be easy, of course, but that was back when I was a n00b and didn’t even know enough to bring up the help buffer for it.

Take a couple of minutes to read mbork’s post. You might learn something you didn’t know.