Alex's Adventures on the Infobahn - code

Many ways to skin a GNU

2012-07-24T15:09:00+01:00

It's time for another examination of Emacs LISP and a selection of ways to solve the same problem. In this case it's the behaviour of the etags-select package. This handy function will present a selection table when it finds multiple definitions of the same tag. This is handy if your global TAGs file contains reference to multiple binaries that might have a common code heritage. It even provides a handy function etags-select-find-tag-at-point which will check point to see if that is a tag. However if point is on a blank line I'd prefer it to just prompt me for a tag name.

First version:

(defun my-naive-find-tag ()
  "Find at point or fall back"
  (interactive)
  (unless (etags-select-find-tag-at-point)
    (etags-select-find-tag)))

Unfortunately this fails rather badly. I naively assumed etags-select-find-tag-at-point would return 'nil on failure. Instead it bombs out with an error because etags-select-find expects a parameter and when find-tag-default fails it errors out.

Second version:

(defun my-working-find-tag()
  "Find tag and call etags-select-find-tag-at-point if it will work"
  (interactive)
  (if (find-tag-default)
      (etags-select-find-tag-at-point)
    (etags-select-find-tag)))

This works by checking find-tag-default will work before calling etags-select-find-tag-at-point. Of course there is some duplication here because find-tag-default will get called again once I know it will work. Dissatisfied I asked the stackoverflow community for suggestions. The first solution is to simply trap the error case.

Third version:

(defun my-try-except-find-tag()
  "Find at point or fall to etags-select-find-tag on error"
  (interactive)
  (unless (ignore-errors (or (etags-select-find-tag-at-point) 't))
    (etags-select-find-tag)))

This works by utilising deep lisp black magic to stop the error propagating and returning a 'nil if it does. The (or (etags-select-find-tag-at-point) 't) line is to ensure a successful call returns something so we don't then fall through. Interestingly the comments around subr.el mentions some of the keywords used may be redefined by common lisp.

Forth version:

(defun my-efficent-find-tag()
  "Find tag at point, caching find-tag-default"
  (interactive)
  (let ((ftd (find-tag-default)))
    (flet ((find-tag-default () ftd))
      (if (find-tag-default)
          (etags-select-find-tag-at-point)
        (etags-select-find-tag)))))

While I expected something like ignore-errors to exist this demonstrates the flexibility of dynamic languages like Emacs Lisp. The key is the use of flet to redefine find-tag-default so when it gets executed again inside etags-select-find-tag-at-point it simply returns the cached value.

So as usual with these posts I try to invite feedback. Which of these forms do you prefer? Would you solve the problem another way? Have you just learnt something new about Emacs Lisp?

completion-ignored-extensions

2011-04-13T16:27:00+01:00

I've been using the rather spiffy Lusty Explorer for some time for my buffer and file finding. However it (I thought) had a rather annoying bug where I could never tab directly into some of the repositories I was hacking on. Eventually I figured out that the problem was down to the way I name them.

My naming scheme for any repository is generally to add the version control extension to the directory. This is more for my benefit than emacs as it's quite capable of working this out for itself in any given repo. However it turns out that Lusty was being a good emacs citizen and using the variable completion-ignored-extensions which included the pattern ".git/" and duly hiding my repo directories from completion. In fact there are a number of patterns in there which should probably be more specific. I wrote this to fix the problem:

(setq completion-ignored-extensions
      (mapcar '(lambda (ext)
                 (if (string-equal "/" (substring ext -1 nil))
                     (concat "^" ext)
                   ext)) completion-ignored-extensions))

It still seems a little ugly to me so given the last time I berated elisp's style gained so many useful suggestions I'd welcome improvements.

Code Insomnia

2010-08-27T06:14:00+01:00

It's very rare programs are ever complete, let alone perfect. I pulled a fairly late session night to push a release out at work. Hopefully testing have a chance to raise any major clangers before I go on holiday for the next month. However the combination of late night coding plus fretting meant I didn't really sleep well. While I may have technically entered REM sleep dreaming about code and architectural deficiencies in your code isn't the most refreshing way to let your brain unwind. I eventually gave up and got up. It's been a while since I heard Farming Today.

Looping in LISP

2010-08-10T09:04:00+01:00

Loops are a fairly important part of any programming language and fairly fundamental to a language that is purported to be all about manipulating lists. However it's not something I use that often in my .emacs code so I thought it might be useful to discuss the various options with some examples.

Problem: I run emacs on a number of machines, each with a different set of sound sets. I want to set up set up a valid sound for erc but I don't want an overly verbose set of cases depending on what machine I'm on. Instead a given a list of sound files I want a function that will return the first one that actually exists.

This problem can be easily generalised into return the first valid path from a list of paths.

First version: pure emacs lisp

; the 'elisp' way
(defun find-valid-file-elisp-way (list-of-files)
  "Go though a list of files and return the first one that is present"
  (let (r '())
    (mapc '(lambda (f)
             (if (file-exists-p f) (add-to-list 'r f)))
          list-of-files)
    (car r)))

First impressions aren't good. The lisp parenthesis do seem to get in the way of making what is happening clear. However it's using one of common mapping functions you see a lot of in lisp. A mapping function essentially takes a list, applies a function to each element of the list and eventually returns a result. The most common of the mapping functions is mapcar which returns a modified list as a result. In this case that isn't what we want so we use mapc where the only value that is built up is the result r as we identify each valid file. The final return value is just the first entry in that list. This does mean we have processed the whole list of alternatives which is sub-optimal.

Second version: Common Lisp Version

(defun find-valid-file-clisp-way (list-of-files)
  "Go though a list of files and return the first one that is present"
  (loop for path in list-of-files
        until (file-exists-p path)
        finally return path))

This version probably is the easiest to read for people familiar with other programming languages. The intention of the code jumps out at you. However the actual implementation is done with a macro. If you look at the help for loop you'll see it can take a number of different forms - follow that to the code and you'll see a fairly complex elisp implementation. However to my mind still easier to follow than the pure elisp version with mapc.

Third Version: Using the dolist macro

; using 'cl-macs
(defun find-valid-file-dolist-way (list-of-files)
  "Go though a list of files and return the first one that is present"
  (dolist (f list-of-files)
    (if (file-exists-p f)
        (return f))))

This is yet another version using an LISP macro but this one has considerably less potential forms to cause confusion. It's fairly comprehensible what is going on and even follows the traditional parenthesis happy form. It also takes advantage of the common LISP return to early return from the loop when we detect a valid file. If it makes it to the end of the list it evaluates the 3rd optional form to calculate the result which in this case will be 'nil.

So what do you think? What version do you prefer? Where does the balance lie between writing code is LISPy ways and for code comprehension? Are there any other ways to solve this particular problem? I'll be looking forward to your comments.