[slime-devel] SLIME User Survey
    Lynn Quam 
    quam at ai.sri.com
       
    Sat Jun 19 22:10:10 UTC 2004
    
    
  
 
>  Which Lisp versions do you use SLIME with?
CMUCL-18e, CMUCL-CVS,  CMUCL-19A-PRE2-X86-LINUX, Allegro-6.0
 
>  Which Emacs versions?
Emacs 21.1.95.1, Emacs 21.2.1
>  How well does SLIME work for you?
Good, much better than ILISP.  
 
>  What bugs (reproducible or otherwise) or missing features annoy you?
.  I wish EDIT-DEFINITION would work better when the source file has
   changed.  I suggest associating a non-trivial hash code (like a
   secure hash function) with the s-expression for each definition to
   be used in finding the definition in a modified source file.
.  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.
.  I wish that the inspector part of the debugger would allow the args
   and locals of the current frame to be inspected. I realize that
   there are no Lisp objects for either, but an a-list or some sort of 
   object could be "consed up" to hold the information.
.  SLIME needs more control over how arrays are printed.
   This is partially a gripe about the CL Spec: *print-array* needs
   counterpart information like *print-length* for lists to control
   how much is printed about arrays.  In particular,
   *print-array-length* = n might mean either print at most the first
   n elements of arrays.  Alternatively, *print-array-length* = n
   might mean to print the array with *print-array* = (<=
   (array-total-length array) n).
>  Is there some packaging system (e.g. Debian) that you would like to
>  see SLIME 1.0 bundled with? If so, do you know how to coordinate
>  this?
   No.
>  If you said anything negative above then please say something nice
>  here to make us feel good:
   My previous suggestions should be not be considered as criticisms
   of SLIME, but as ways to improve it.
   I have been grumbling for many years about the problems with the
   ILISP communication model.  There always seemed to be something
   wrong with the regular-expressions used to detect the REPL prompt.
   SLIME appears to have avoided those problems by having a distinct
   stream for the REPL buffer (and other things) vs control and
   asynchronous communication.
   Good work,  SLIMIES (or is it SLIMERS?).
    
    
More information about the slime-devel
mailing list