Lynn Quam quam@ai.sri.com writes:
Luke Gorrie replied:
In what cases does it cause you problems under CMUCL? I thought that the source-file-cache hack pretty much took care of this.
I have noticed that in files with reader-macro conditionals that have undergone insertions and/or deletions of code that EDIT-DEFINITION sometimes gets me to the wrong place. Recently, I have seen that I have been getting to the next definition after the correct one. EDIT-DEFINITION should really also consider reader-macro conditionals.
If you can send me reproducible examples I'll try to fix them. No rush though, in playing around I've just found one case that should work but doesn't, so I've got some fixing to do.
Perhaps I am nitpicking, but it is possible for there to be 2 definitions in a file with the same first 256 characters.
A long hash code like that of the NIST Secure Hash Standard ("Applied Cryptography", Bruce Schnier) is extremely robust wrt modifications to the input string.
I'm thinking of robustness in the opposite sense: if I'm looking up the definition of FOO, but FOO has been modified, then a hash won't find it but a best-prefix-match search quite possibly will. Looking for definitions that have been modified since compilation is fairly common for me I think.
It's possible to make the snippet longer than 256 characters, but I figured that was probably more than enough in practice. Also, the search starts from the expected character-position and if there're multiple best-matches then it will choose the nearest one.
If you want to be extreme you could e.g.
(setq swank-backend::*source-snippet-size* most-positive-fixnum)
That way the "snippet" would be the complete source code from the beginning of the definition until the end of the file.
More ideas would be welcome. But hashing seems more sensitive to changes in the sought-after definition than I'd like.
For now I'm suspecting that any problems you're seeing are due to bugs rather than limitations of the snippet-based algorithm.
-Luke