Lynn Quam quam@ai.sri.com writes:
It seems to me that using a good hash code over the entire s-expression of the definition would be even better.
The trouble with a hash is that it's very sensitive to modifications and can be difficult to locate the matching text has moved.
But we can send the whole definition text and then match that if we like. Currently it sends 256 bytes which I figure will be enough for most cases.
It would be interesting to have a string matching algorithm that handles modifications better than incremental-prefix-search, as Alan suggested.
It would be useful if the underlying lisp implementation could be convinced to include more source location information in the compiled object file. In this way, source version info, such as RCSID, and/or file date and time stored in the object file. In the absence of RCSID, file date and time could be useful in determining the source file version associated with the object file. Similarly, the sexpr hash code could be stored for each definition in object file.
CMUCL does store the FILE-WRITE-DATE of the source file, so we can tell if the source has been modified. Currently I use this to cache the source file if it is known to be unmodified, so that if it is later edited we still have a good copy. (Even in defun-at-a-time hacking one often saves the Emacs buffer I think.)
I'm not 100% sure that the cache is worth the bother yet, though. I will experiment some more.
[About falling back on regexps]
Unfortunately, using totally different strategies for finding the definition source depending on whether the file has changed, is likely to lead to confusion for the user, as is often the situation with Ilisp. There are several things that might improve the situation:
I've removed the fallback-on-regexp code now. It could possibly be useful as an optional feature but for now Helmut has convinced me that source-paths are good enough.
It did solve the problem I have of finding definitions in CMUCL's CVS sources while running 18e, but this is a weird thing to be doing in the first place :-).
Cheers, Luke