[slime-devel] More steroids for M-. in CMUCL (Was: Re: SLIME Edit Definition)

[Luke Gorrie]

Ahoy,

I've hacked M-. in CMUCL to handle some cases of file/buffer
modification better. Some of the mechanism is generic and might be
useful for more backends in future.

I've tested all the cases I can think of and checked it in. I haven't
given it as much real-usage testing as I'd like but I'm in a hurry to
free up my sunday for beer drinking :-)

Background: The Lisp side of M-. in CMUCL works by finding out the
filename and "source path" of the definition and then opening the file
and doing some special READ-magic to find the exact character position
of the definition. It then sends this position to Emacs, which does a
`goto-char' to get there. This works extremely well if neither the
file nor the Emacs buffer are modified, but otherwise it gets in
trouble.

First consider the case where the source file hasn't been changed but
the Emacs buffer has. The new idea is: since Lisp pulls up the source
and finds the exact right position, how about grabbing the opening
snippet of the function (a hundred bytes, say) and sending it to Emacs
as a "hint"? Then Emacs can jump to the hopefully-right position and
then do a bi-directional isearch for the longest match of the actual
function prelude.

This seems to work very well. It's based on the seemingly reasonably
assumption that if the definition of BAR started with "(define-foo bar
..." before then it probably still does now. The same trick is used
for interactively compiled definitions.

This solution seems near ideal, but it does only work when Lisp can
find the source file version that the code was compiled from. If it
ever finds such a version then it caches the whole file in the Lisp
image so that the next `C-x C-s' won't spoil the fun. Files will go
into the cache the first time you M-. into them -- probably it would
be better to suck them in as soon as they enter slime-mode, but I
haven't tried that yet.

Now for the case where the file on disk has been changed. Source-paths
can tollerate a bit of this but it does get nasty easily, e.g. M-. on
CMUCL symbols usually doesn't work for me because I run random
binaries but always against the CVS sources, and usually land one or
two defuns away from the real definition.

For this case it now just detects that the file is modified and falls
back to regexp-based search, the same way e.g. the OpenMCL backend
works. This seems to work pretty well. I also tweaked the regexps a
bit, hopefully for the better.

With luck this will make M-. going to the wrong place a rare occurence
for CMUCL users. If problems persist then please let us know!

Cheers,
Luke