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.
In the current scheme our "hash" is just the first 256 characters of the definition, for which we find the longest match. I don't see what interesting cases a real hash function would handle that this doesn't, and it would seem less robust wrt modifications to the definition that's being looked up. Am I missing something?
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.
. It would be nice if s-expressions for reader-macro conditionals that evaluate to NIL in the running Lisp were displayed in a different Emacs face. SLIME aleady has slime-eval-feature-conditional with evaluates the reader conditional wrt. *features* of running Lisp.
This would be good. Right now I don't know of the right mechanism by which to do it. Anyone have ideas?
There is the Emacs hide-ifdef-mode that might provide some ideas for this.