Irreal

Marcin Borkowski (mbork), who’s an occasional commenter here on Irreal, has an interesting post on his info workflow. He likes to have multiple info buffers open at the same time. That may seem a little odd but as Borkowski explains, he is often working on something in Org mode, say, and needs to check something in the Elisp manual.

It is possible, of course—it’s Emacs, to have multiple info buffers but it’s a bit clumsy. Borkowski wanted to be able to pop up an info buffer immediately whenever he needed it. To do that, he wrote a bit of Elisp to open an additional info buffer (or switch to an existing one) for any info manual. Then he wrote some additional code to call his function for his most often used manuals and bound them to quick key sequences.

A nice solution and another great example of how Emacs makes it easy to adjust it to accommodate your workflow. Head on over and take a look at his code. It may be something that you can use too.

Via Sacha I found this really interesting post by John Kitchin, whose work Irreal has mentioned many times. In this post, Kitchin writes about how he used Emacs to run a graduate course in Chemical Engineering. Emacs was used to handle everything in the course.

When I say “everything,” I mean everything. As Kitchin says

Every lecture was given from Emacs, every assignment completed in Emacs, turned in from Emacs, graded in Emacs, returned in Emacs.

Kitchin provided each student with a custom Emacs environment that included all the tools he uses for interfacing with Python and for making engineering calculations. In addition, he included a package he calls techela that interfaces with git and handles student assignment submission, quiz and exam taking, retrieval of grades, and other similar chores.

Course administration generally takes a significant amount of a professor’s time. Kitchin’s set up eliminates much of the busy work. Read the post to get an idea of how pervasive Emacs was in the course. As usual, Kitchin exploits Emacs in novel ways that makes his work much easier.

Over at the Emacs Reddit, tending asks how to fall back to a known good Emacs configuration when initialization gets an error. His complaint is that if there’s an error early in his .emacs file, the initialization is aborted and he’s dumped into a default Emacs that doesn’t have his usual environment. We’ve all been there.

Last time I looked, no one had a solution for falling back to a known good configuration but Renan Ranelli pointed to his solution for the problem. Ranelli’s approach is to divide his configuration into several files—as many Emacs users do—and then have a small “bootloader” that loads each file but within a condition-case that captures any errors and records them. The rest of the files (assuming no further errors) are loaded normally. At the end of the loading, any errors are reported but most of his environment is available.

It’s a very nice solution and, if you already have your configuration divided into separate files, very easy to implement. Take a look at his init-bootstrap.el file. You may find you want to do something similar. You could even use the same idea to implement the solution tending was seeking.

Oleh Krehel (abo-abo) has a new blog, (or emacs. There’s only a few posts so far but they’re really excellent. For example, his initial post discusses his packaging of ace-window into a library so that other packages can use the ace-window technology to pick windows to operate on.

I really like ace-window and use it all the time. I didn’t know, though, that with 【Ctrl+u】 it will swap the current window with the selected one and with 【Ctrl+u Ctrl+u】 it will delete the selected window. So I learned something useful from his very first post.

Abo-abo has made many contributions to Emacs other than ace-window so he has interesting things to say. Welcome, abo-abo. We’ll be looking forward to many more posts.

I use iBuffer a lot. That’s probably because I get a little OCD about stray buffers eating up memory for no reason. With my new 16 GB laptop, buffers eating up memory isn’t much of a problem but it’s too late for me to reform my ways.

I especially like to clean up after I upgrade my packages. That process always leaves a Compile-Log buffer at the top of the iBuffer list and a Packages buffer at the bottom. Of course, when I navigate to the head or tail of the buffer I end up in the wrong place—not at the head or tail of the list.

If that seems a little familiar it’s probably because Magnar Sveen had similar problem with dired and solved it with a bit of Elisp. So I shamelessly ripped off Sveen’s code and made a few trivial changes so it does the same thing for iBuffer that Sveen’s did for dired. If you’re having the same problem, the code is below. It’s almost embarrassing to post it because it’s such a rip off but Emacsers who don’t have the wherewithal to figure out which key map to use or who don’t know Elisp may find it useful.

;; Stolen from Magnar's code to do the same thing for dired
;; http://whattheemacsd.com/setup-dired.el-02.html
(defun ibuffer-back-to-top ()
  (interactive)
  (beginning-of-buffer)
  (next-line 3))

(defun ibuffer-jump-to-bottom ()
  (interactive)
  (end-of-buffer)
  (next-line -2))

(eval-after-load 'ibuffer
  '(progn
     (define-key ibuffer-mode-map
       (vector 'remap 'end-of-buffer) 'ibuffer-jump-to-bottom)
     (define-key ibuffer-mode-map
       (vector 'remap 'beginning-of-buffer) 'ibuffer-back-to-top)))