Emacs Find of the Day: Repeating Commands

One thing that I love about Emacs is that even after 20 years, I’m finding new (old, in actuality) functionality that makes my life better.

Today’s example is repeat-complex-command, which is normally bound to ctrl-x ESC ESC, as noted on the emacs wiki. The problem in my world is that I’m also using CUA mode, from the ergoemacs library, which redefines ctrl-x to do cuts (as in cut, copy, paste).

Normally that doesn’t cause an issue, since if you don’t have a region marked, then ctrl-x is apparently ignored by ergoemacs and is delegated to the default behavior, in which case ctrl-x ESC ESC brings up the previous command in the echo area, ready to be edited.

However, what has arisen as a nuisance in my experience is when I’ve done a search and replace in one region, then want to do a similar but not identical search and replace in a different region, such as renaming variables in two methods.

Normally I’d mark the first method, run search and replace (query-replace or query-replace-regexp), then go to the second method and mark it. At that point I’d like to bring up the previous search-and-replace and modify the command, but when I hit ctrl-x, the currently-marked region (the second method in this example) is cut, per behavior from ergoemacs.

The fix is to map a different key, in my case alt-j alt-j (the mnemonic being that the keys repeat) mapped to repeat-complex-command, per this snippet from my .emacs file(s):

(define-key global-map (kbd "M-j") jep:keymap)
(define-key global-map (kbd "C-j") jep:keymap)

;; CUA settings muck up ctrl-x, so use an alternative, alt-j alt-j:
(define-key jep:keymap (kbd "M-j") 'repeat-complex-command)

Yes, I map both alt-j and ctrl-j as equivalent keys that define my keymap, making it simpler when I have shortcuts that are prefixed with alt- and ctrl-. So alt-j alt-j flows better, as does ctrl-j ctrl-l (which inserts logging statements, if you’re wondering).

All of this is available at my github repository.

But wait — there’s more: the second nugget of the day is that after running repeat-complex-command, the echo area will display the previous command, of course. But then running alt-p will bring up the command prior to that, and alt-p the command prior to that one, etc. On the other hand, and in the opposite direction, alt-n moves forward through the list of commands.

I hope this helps, and I plan to post more about Emacs and what I find therein.

Emacs and colors being reset

I ran into this today, and couldn’t find a quick answer online.

I was updating yasnippet to the current release, and there was an error on startup about dropdown-list.el not be able to be found. That resulted in Emacs aborting the startup process before it reached the settings in my .emacs file that define the color settings.

So Emacs initialized with the default colors (dark on light), whereas my custom settings are light on dark. When I then exited Emacs, it saved the .emacs.desktop file, which I’d thought was just the list of files. However, it also contains the color settings, so after I’d worked around the yasnippet issue, and started Emacs again, it used the default color settings (from the loaded ~/.emacs.desktop file) instead of mine in .emacs.

The fix was to remove the line that begins with “(setq desktop-saved-frameset”, exit Emacs and start it again, in which case the color settings will be loaded from ~/.emacs instead. The next time Emacs is exited (or just desktop-save is run), then the color line in ~/.emacs.desktop will be updated.

This is probably quite an edge case, but I thought perhaps others might run into this issue. I hope this helps.

Rails testing and Emacs mode line

I’ve been diving/digging into the oh-so-excellent Rails Tutorial, by Michael Hartl, and am into chapter 3, where testing begins.

Imagine my surprise — go ahead, imagine it — when my Emacs mode line changed color.



And when I ran “bundle exec rake test”, it succeeded with:


Then changing the test code to fail, after running “bundle exec rake test” again:


Tracking down this code, I found that the guard-notiffany gem was doing this behavior, sending a change to the Emacs mode line via emacsclient, with this bit of code in lib/notiffany/notifier/emacs.rb:

        def notify(color, bgcolor)
          elisp = <<-EOF.gsub(/\s+/, " ").strip
            (set-face-attribute 'mode-line nil
                 :background "#{bgcolor}"
                 :foreground "#{color}")

The issue there was that it just changes the mode line “permanently”. I’d prefer that the mode line colors change for a moment, then time out and revert to their previous settings.

I wrote a bit of code to do this, and modified lib/notiffany/notifier/emacs.rb locally, but there is a pending pull request that has a better implementation.

However, my hack is:

        def notify(color, bgcolor)
          elisp  = "(let ((orig-bg (face-attribute 'mode-line :background))"
          elisp << "      (orig-fg (face-attribute 'mode-line :foreground)))"
          elisp << "     (set-face-attribute 'mode-line nil"
          elisp << "                         :background \"#{bgcolor}\""
          elisp << "                         :foreground \"#{color}\")"
          elisp << "     (sit-for 3)"
          elisp << "     (set-face-attribute 'mode-line nil"
          elisp << "                         :background orig-bg"
          elisp << "                         :foreground orig-fg))"

The sit-for keeps the mode line as red or green for 3 seconds or when there is Emacs input. I prefer that, to clear the mode line more quickly, since I find the bright color distracting.

Adding Groovy Emacs Mode

I’ve been doing a lot of Gradle/Groovy work lately, and have been using Russel’s Groovy Emacs Mode.

That page provides the documentation for the case where you’re going to put all the *.el files into ~/.emacs.d. However, to keep things nice and organized I put third-party code into a vendor directory under ~/.emacs.d/lisp.

So for the Groovy mode, I added ~/.emacs.d/lisp/vendor/groovy-mode, extracted Russell’s tarball into that, and added these lines to my jep-groovy.el file:

;;; use groovy-mode when file ends in .groovy or has #!/bin/groovy at start
(add-to-list 'load-path "~/.emacs.d/lisp/vendor/groovy-mode")
(autoload 'groovy-mode "groovy-mode" "Major mode for editing Groovy code." t)
(add-to-list 'auto-mode-alist '("\.groovy$" . groovy-mode))
(add-to-list 'auto-mode-alist '("\.gradle$" . groovy-mode))
(add-to-list 'interpreter-mode-alist '("groovy" . groovy-mode))

;;; make Groovy mode electric by default.
(add-hook 'groovy-mode-hook
          '(lambda ()
             (require 'groovy-electric)

Shorter Directory Names in Emacs Ibuffer and Mode Line

I use Emacs and Z shell exclusively, and have been frustrated at times about the features in Z shell that are not in Emacs, one being the shortened directory names. These are used for navigating (changing directories and displayed in the prompt), and are especially useful with long/deep directory names.

In Java projects, this is beneficial, because the hierarchy tends to be so deep. For example, with the path:


In Z shell the directory can be given a short name with:

   hash -d projectx=/home/me/proj/com/mycompany/projectx/trunk

So the file can be referred as:

   less ~projectx/src/main/java/com/mycompany/util/FooUtil.java

And this can be done more extensively than that, such as:

   hash -d pxutil=~projectx/src/main/java/com/mycompany/util

And used as:

   less ~pxutil/FooUtil.java

That also makes for a shorter directory name displayed in the prompt, such as this for DiffJ:


Which without Zsh hashes would be:


So I’ve become used to that in my shell, but have been frustrated with my editor, which shows the full path in the default ibuffer display, running out to over 100 columns:

    TokenList.java   1699 /home/jpace/proj/org/incava/diffj/src/main/java/org/incava/diffj/code/TokenList.java

It also seemed redundant that in the above, TokenList.java is displayed twice, so the filename-and-process column could be replaced with only the directory name.

I looked around for examples about changing the columns in ibuffer, but found few examples, mainly the same code repeated on various sites online, variations of this from http://www.emacswiki.org/emacs/IbufferMode:

;; Use human readable Size column instead of original one
(define-ibuffer-column size-h
  (:name "Size" :inline t)
   ((> (buffer-size) 1000000) (format "%7.3fM" (/ (buffer-size) 1000000.0)))
   ((> (buffer-size) 1000) (format "%7.3fk" (/ (buffer-size) 1000.0)))
   (t (format "%8d" (buffer-size)))))

That was a starting point, but I couldn’t find anything more about revising the filename-and-process column, which shows the above long path.

The following code adds a ‘dirname’ format to ibuffer to shorten the filename and show only the directory:

(defvar jep:filename-subs
  '(("/home/jpace" . "~")
    (".*/Projects/com/mycompany/is/" . "~is/")
    ("/home/jpace/proj/org/incava/" . "~incava/")
    ("/$" . "")))

(define-ibuffer-column dirname
  (:name "Directory"
	 :inline nil)
  (if (buffer-file-name buffer)
      (str-replace-all (file-name-directory (buffer-file-name buffer)) jep:filename-subs)
    (or dired-directory

(setq ibuffer-formats
      '((mark modified read-only " "
	      (name 30 30 :left :elide)
	      " "
	      (size 9 -1 :right)
	      " " dirname)
	(mark modified read-only " "
	      (name 30 30 :left :elide)
	      " "
	      (size 9 -1 :right)
	      " " filename-and-process)
	(mark " "
	      (name 30 30 :left :elide)
	      " " filename-and-process)))

Now my ibuffer looks like:

[ diffj ]
    TokenList.java    1699 ~incava/diffj/src/main/java/org/incava/diffj/code
    build.gradle       892 ~incava/diffj

Much better.

Coincidentally, I had the same complaint about the modeline, which defaults to the same display as ibuffer, with the full path of the file. So I tweaked the modeline code to do the same:

(defvar jep:modeline-subs
  '(("/home/jpace/" . "~/")
    (".*/Projects/com/mycompany/is/" . "~is/")
    ("/proj/org/incava/" . "~incava/")
    ("/$" . "")

(defun jep:modeline-dir-abbrev ()
  (str-replace-all default-directory jep:modeline-subs))

(setq default-mode-line-format
      (list ""
            " ["
            '(:eval (jep:modeline-dir-abbrev))
            "] "
            '(-3 . "%P")

Note that the modeline and ibuffer code above uses this function, which I put in ~/.emacs.d/lisp/str.el:

(defun str-replace-all (str pats)
  (if (null pats)
    (let* ((pat (car pats))
	   (lhs (car pat))
	   (rhs (cdr pat)))
      (replace-regexp-in-string lhs rhs (str-replace-all str (cdr pats))))))

So there is my contribution. Here it is in action:


And it’s included with my Emacs configuration on GitHub.

Tweaking Emacs: Snippets

Using snippets with Emacs has dramatically increased my productivity. I’m using YASnippet, and am thoroughly impressed by it.

Setup is easy, so I won’t repeat that here.

I put my own snippets in ~/.emacs.d/lisp/yasnippets/snippets/java-mode and …/ruby-mode, and you can see them here.

The obvious benefit with snippets is their brevity, usually replacing unnecessary or redundant boilerplate code, such as this one for creating a list in Java:

# name : List<String> list = new ArrayList<String>();
# key: list
# --
List<${1:String}> ${2:list} = new ArrayList<$1>();$0

So creating a list of Integers, named “numbers” is done with “listIntegernumbers”.

Naturally, since this is Emacs, there is a real programming language available for use, so snippets can call Emacs Lisp code, such as this for creating a constructor in Java, which assumes the constructor name is the basename of the current file:

# name: constructor
# contributor: jpace317@gmail.com
# key: init
# --
public `(file-name-nondirectory
	  (or (buffer-file-name)
	   (buffer-name (current-buffer)))))`($1) {

This is simply applying the principle of automating work as much as possible. In the words of Larry Wall: “The computer should be doing the hard work. That’s what it’s paid to do, after all.”

There are two other aspects about using snippets that I think are overlooked. At least I hadn’t expected them when I began using snippets.

The first is that snippets can essentially provide their own documentation. That is, the syntax ${1:String} above means that the default text “String” will be displayed, until and unless the programmer overwrites it with the different variable type. This is especially beneficial for what often confuses me, the order of the iterated variable, and the accumulator variable (injection below, and I’ve also seen it called memo).

With snippets, the default text describes the variable functionality. Voila and viola, no more confusion:

# name: inject(...) { |...| ... }
# key: inject
# --
inject(${1:0}) { |${2:injection}, ${3:element}| $0 }

The third benefit of snippets is that they add consistency across programming languages. My two primary languages are Java and Ruby (day job, night job), and I’ve added snippets to Java and Ruby mode for common functionality. For example, the Java snippet “constructor” above has the shortcut “init”, as does my snippet for Ruby mode:

# name : initialize
# key: init
# --
def initialize $1

Thus when I’m writing a constructor in either language, all I need to type is “init”. I’ve done the same for initializing instance variables with the same name as a constructor parameter, these two “svar” snippets (“svar” == “set variable”):

# name : set_variable
# key: svar
# --
@$1 = $1
# name : set instance variable
# key: svar
# --
this.$1 = $1;

What drove me somewhat crazy when editing snippets was that Emacs defaults to adding a final newline at the end of a buffer when saving it. Thus when I used one of my snippets, an extra line would be added. (For some snippets, I do want a newline, such as shortcuts for adding methods and constructors, which should be separated from other methods by a blank line.)

I knew of one solution, changing mode-require-final-newline to nil, but I didn’t want to change the global settings. I figured that YASnippet might have its own mode for editing snippets, and indeed it does, and even better, in that mode, a final newline isn’t written.

I set snippet-mode for my snippets with this:

(add-to-list 'auto-mode-alist '("\\.emacs.d/lisp/yasnippet/snippets" . snippet-mode))

Please do yourself a favor and check out YASnippet.

Sharpening the Emacs Saw

Emacs has been my primary/only editor for around 20 years, and I’ve become more aware of how little of its power I actually use. Emacs Rocks has been very inspirational in motivating me to further explore the functionality of Emacs. Lately I’ve been applying the DRY principle to Emacs itself, where if I find myself repeating a sequence of commands (including characters) in Emacs, I’ll write a macro or snippet (using YASnippet, which I highly recommend).

Integrating this approach with the Pomodoro and/or Getting Things Done principles, whenever I find myself repeating, er, myself, I’ll stop and add that sequence as appropriate, usually as a change to either my Emacs environment or my shell (Z shell) setup. It might be a bit of a distraction, diverting my attention for a minute or two, but the benefit is that I can begin using the new shortcut immediately. In fact, to enforce the new shortcut, if I accidentally use the equivalent long sequence, I’ll back up (such as deleting the just-typed characters) and use the new shortcut instead. This helps to erase the old muscle memory and enforce good, new habits.

YASnippet is especially valuable in automatically generating the boilerplate so much required by programming languages, especially Java. Even Ruby has its own overhead, and I recently heard (I’m about eight months behind) on a Ruby Rogues podcast that essentially if a Ruby programmer is actually typing “end”, then their environment is not adequately customized. I’d add that the same would apply to curly braces in Java and other C-derived languages.

A rule of thumb I’ve read is to add one script per day, and I’d advise the same for one’s editor, whether it be Emacs or any other powerful editor that can be customized, as virtually of them can be now. PragProg now has a new Vim book, Practical Vim. I don’t know of an equivalent book for Emacs, but it seems that there would be a market for it.

Ergonomic Emacs Keybindings

I just spent three days trying out Xah Lee’s ErgoEmacs – ergonomic Emacs keybindings – and I’ve been impressed. Easier in terms of typing, given that the most frequent commands are defined as Alt-. (where “.” is a single key) instead of as Ctrl- (or worse, Ctrl-C Ctrl-.). Thus “Emacs pinkie” is less likely, since the thumbs are more heavily used on the the Alt keys instead of the pinkies working the Ctrl keys.

Setup is trivial. Just grab the zip file, unzip it into ~/.emacs.d, and add the following to your ~/.emacs file:


;; load ErgoEmacs keybinding
(load "~/.emacs.d/ergoemacs-keybindings-5.3.9/ergoemacs-mode")

;; turn on minor mode ergoemacs-mode
(ergoemacs-mode 1)

Among the first things to do is, at least if you’re running with the default Gnome keyboard shortcuts, is to disable alt-space from raising the menu within terminals (at least, this is the case for gnome-terminal). To do this, change or disable the shortcut via Preferences > Keyboard Shortcuts > Desktop > Show the panel’s main menu. Select that, hit backspace, and it should now read “Disabled”.

ErgoEmacs is actually two modules in one: it first is, as its name says, a more ergonomically friendly version of Emacs, where commonly-used commands have easy-to-type shortcuts, that is, with the use of Alt instead of Ctrl, and by favoring the keys in the center of the keyboard, as opposed to [, ], \, ~, etc.

The second module is that it uses the now-standard (for lack of a better word) editor shortcuts for operations such as opening files, copy, cut, and paste, which is much more intuitive and consistent with other editors.

I like much of it, but have some issues. I agree that the default Emacs keybindings and behavior are difficult, overwhelming and inconsistent with other editors, and should be updated. However, as with the Qwerty keyboard, we’re essentially stuck, by “we” I mean Unix-based programmers using Emacs, especially the most experienced ones. ErgoEmacs seems designed best for people experienced with mainstream editors such as Notepad and TextMate.

Emacs is so second-nature to me that I don’t consciously know some (most?) of the key shortcuts. If you’re like that, chances are that ErgoEmacs will force you to think about the shortcuts, causing cognitive friction that will interrupt your flow. If you have RSI issues, then you’re more likely to benefit, although as a programmer, I’m typing the oddball keys ([], {}, ()) so much that it is not significant to me to have the less frequently used commands a bit easier to type. (I’d never thought of that before, but it’s another reason to like Ruby: fewer special characters, since for example blocks are delimited with “begin” and “end” instead of “{” and “}”.)

The tipping point for me against ErgoEmacs is that my shell, Z shell, does not have the equivalent shortcuts, so I would essentially have to remember two separate (and conflicting) sets of commands.

That brings me to my final point: I dislike that ErgoEmacs provides no bridge or transition period for going from standard Emacs to ErgoEmacs. I’ve read that one can provide hints (in the same way that vanilla Emacs suggests shortcuts after you’ve executed a command via the traditional (M-x whatever). Having this with out-of-the-box ErgoEmacs would have been nice.

That said, I like the principle behind ErgoEmacs, and I’ll certainly be taking some ideas from it. On that note, I’ve finally posted my Emacs environment, 16 years of cruft and all, on GitHub here. I’ll be actively refining it over the next few weeks, and intend to have it up to date and stable by the end of January.

Timelessness of Quality

I’ve been rereading Hackers and Painters, by Paul Graham, and his chapter on Lisp was especially interesting, given that I’ve been working on expanding my Emacs knowledge and further refining my environment.

The connection between Lisp and Emacs? In this sense, they both became the standard-bearer for their field (programming languages, text editors), and reached that point very soon after the inception of the field. Each of them was so far ahead of the others that even decades later, one could argue that neither Lisp nor Emacs has been matched. If anything, progress in the fields has just been that the mainstream (meaning, widely accepted) products are more and more like Lisp and Emacs.

This doesn’t seem atypical, that there is this quantum leap early in the field. Among guitarists the Gibson Les Paul and Fender Stratocaster are probably the two most popular electric guitars, even a half century after their initial release in the late 1950s, when the electric guitar originated. In my non-expert vantage point I don’t perceive a fundamental difference (as in performance and function, not appearance) between the newest guitars now and the original Strat and Les Paul.

As Graham does, the same argument could be made for Ruby and Lisp, that of “modern” programming languages, Ruby is one of the closest to Lisp in terms of functionality (although its form is somewhat different). About Emacs, I don’t know what other text editor could be considered close, but it seems that Emacs is the most imitated – for example, it seems that the Eclipse editor is much closer to Emacs in behavior than it is to, say, vi. (On that note: is any other text editor similar to vi?)

It seems that the cycle is somewhat like this: the field originates, there are a few competing lead products, one dominates clearly, then there are relatively few imitators for the next decade or two (or more). After a while, the imitators become better and more like the original, to the point that they are essentially just re-badging it.

I’ve tried several times to really learn Lisp in the past, but had difficulty hurdling the syntax, probably in part because of my background in C, Perl, C++ and Java. But having now read of the similarities between Lisp and Ruby, I’m eager to see the difference in my perspective as I go through the excellent Emacs and Emacs Lisp tutorials at Xah Lee’s Emacs Blog).

Emacs and Copying in X

One of the most annoying things I’ve found with GNU Emacs and other programs in X is that copying/cutting doesn’t work with the X clipboard, by default.

The fix is to rebind the cut and copy shortcuts to the equivalent X clipboard functions:

(global-set-key "\M-w" 'clipboard-kill-ring-save)
(global-set-key "\C-w" 'clipboard-kill-region)