Alex's Adventures on the Infobahn - elisp

dired-rsync 0.4 released

2018-06-01T18:12:00+01:00

I started hacking on this a while back but I've finally done the house-keeping tasks required to make it a proper grown up package.

dired-rsync is a simple command which you can use to trigger an rsync copy from within dired. This is especially useful when you want to copy across large files from a remote server without locking up Emacs/Tramp. The rsync just runs as an inferior process in the background.

Today was mainly a process of cleaning up the CI and fixing any issues with it. I'd still like to add some proper tests but the whole thing is interactive and that seems to be tricky for Emacs to test. Anyway I've now tagged 0.4 so it will be available from MELPA Stable once it rebuilds. You can of course grab the building edge from MELPA any time ;-)

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?

Perils of bleeding edge

2011-07-27T16:55:00+01:00

I've taken to running the latest emacs from a source tree install. It works well enough and additional modes I use have been liberally ${VC} fetched into my .emacs.d. However there are still a number of packages I'd like to use from Debian's emacs version agnostic site-lisp directories. I came up with this:

 ;; Add site-lisp to search path
;
; This is a work-around function for when I'm running bleeding
; emacs from the source tree but still want Debian's developer
; tools. I'd caution about having too many extra packages about that
; have been merged into the source tree (cedet etc) lest it get
; confused.
(defun load-debian-site-lisp()
"Attempt to load Debian's site-lisp if it's there"
  (interactive)
  (when (and (not (member "/usr/share/emacs/site-lisp" load-path))
             (fboundp 'normal-top-level-add-subdirs-to-load-path))
          (let* ((default-directory "/usr/share/emacs/site-lisp"))
      (normal-top-level-add-subdirs-to-load-path))))

(load-debian-site-lisp)

Which seems to work well enough to give me my debian-changelog-mode back. However it's still not seamless as I have to manually (require 'debian-changelog-mode) before loading a changelog which forces the issue with local variables. I suspect I'll have to replicate the boilerplate that /usr/share/emacs/site-lisp/debian-startup.el does but I can't use because it doesn't degrade gracefully if no debian-emacs-flavour is defined. Suggestions for making this behaviour neater would be useful....

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.

Edit with Emacs v1.8

2010-08-19T11:10:00+01:00

After a relatively quiet period a number of patches have flowed my way so I thought it was worth pushing out a new version. Perhaps the most "important" feature is the edit box flashing and fading from yellow after being updated (like It's All Text). It wasn't that hard to do given jQuery and the colour animation plugin do all the heavy lifting.

We've added a new hook to the edit-server for pre-edit customisation. If anyone has some nice examples of using the various hooks it would great if you could add examples at the emacs wiki.

As ever the extension can be found at the Chrome Extensions site. Development versions are hosted at github.

Full Change Log

v1.8

Extension

* Added option to enable/disable visual edit boxes
* Improved feedback as editable elements come in and out of focus
* Updated text box will now fade from yellow after an update

edit-server.el

* Added edit-server-start-hook for additional customisation when edit starts

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.

First elisp patch for emacs chrome

2010-01-09T12:40:00+00:00

One of the nice things about putting your coding experiments up early and under a permissive license is people can submit patches. I'd been trying to get the native elisp edit server working but I'd fallen back to the working python script as I've been busy at work. However along comes Riccardo Murri who cleaned up the code and got it working. I've pushed the changes to the repo and with a little extra glue spawn it when emacs is in --daemon mode:

;; Do we want an edit-server?
(if (and (daemonp) (maybe-load-library "edit_server"))
    (edit-server-start))

And bingo you save the cost of 2 unnecessary fork/execve's to get emacs editing your Google Chrome(ium) hosted <textarea>. It seems to have an odd interaction with longlines-mode though which I need to investigate, perhaps longlines mode does magic stuff with the buffer text on save which gets skipped when the edit server does it's thing?

I've submitted the extension to the Google extension gallery although it's currently held up in actual physical paperwork. As my content script needs fairly liberal permissions to work I have to at least demonstrate I'm not an evil hacker/spammer intent on creating browser malware. I may take advantage of the delay to some clean ups to the browser feedback as we will likely be housebound sheltering from the weather. That is of course unless anyone else beats me to it :-)