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