[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