Christophe Weblog Wiki Code Publications Music
rework commands in light of long cache refresh time
authorChristophe Rhodes <csr21@cantab.net>
Mon, 11 Jun 2012 10:33:21 +0000 (11:33 +0100)
committerChristophe Rhodes <csr21@cantab.net>
Mon, 11 Jun 2012 10:33:21 +0000 (11:33 +0100)
commit561c68511a2aa272c658192b6e1c08fe666196ed
treedc5ca56192ab8e8f6634afc23a0722ada4eb8266
parentd78f76fee563d2fd51a4ec613fe2d9d955e8877c
rework commands in light of long cache refresh time

The issue is that of get-iplayer itself managing its cache: if at any
point it decides that the cache is sufficiently stale, it goes off and
refreshes everything, which seems to take a long time -- if I'm
unlucky, breaking my ERC sessions (and in any case making the rest of
the editor session unusable).

Construct a background process and sentinel to manage the cache
updating before calling the real get-iplayer command.  The tricky bit
here is to make sure that the sentinel and real body get executed in
the right context.  Many things in the world are simpler with lexical
scoping; this would have been one of them, but I am still on emacs 23
and lexical binding is a thing of the future, so instead of making a
bunch of thunks to be called later, we have to save commands (well,
key sequences), but then those key sequences are divorced from the
window and frame that they were originally typed into, so we have to
get that context back.  Naive ways of doing that turn out not to work,
because execute-kbd-macro runs its own command loop, which first of
all selects a current frame and window, so if we've navigated away
from the *iplayer* window/buffer we end up adding keystrokes to
e.g. an ERC buffer, which is suboptimal; however, (ab)using the pre
and post command hooks seems to make things work.  So do that, and all
is well.
iplayer.el