[slime-devel] Re: SLIME User Survey

[Lynn Quam]

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.