- slime-devel - mailman3.common-lisp.net

[slime-devel] patch: print-slot-for-emacs
by Larry D'Anna 29 Jun '07

29 Jun '07

Here's a little patch that adds a generic function print-slot-for-emacs that can be used to customize how a slot is printed. For example if you want a particular slot which holds a number to be displayed in hex: (defclass barclass () ((foo :initarg :foo) (bar :initarg :bar))) (defmethod print-slot-for-emacs (class (object barclass) slot) (if (eq (swank-mop:slot-definition-name slot) 'bar) (format nil "~2,'0X" (swank-mop:slot-value-using-class class object slot)))) ;;;inspect this (make-instance 'barclass :foo "foooooo" :bar 255) Index: swank.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank.lisp,v retrieving revision 1.490 diff -u -r1.490 swank.lisp --- swank.lisp 4 Jun 2007 16:17:17 -0000 1.490 +++ swank.lisp 29 Jun 2007 18:12:54 -0000 @@ -4779,12 +4779,18 @@ maxlen (length doc)))) +(defgeneric print-slot-for-emacs (class object slot) + (:method (class object slot) + (declare (ignore class object slot)) + nil)) + (defgeneric inspect-slot-for-emacs (class object slot) (:method (class object slot) (let ((slot-name (swank-mop:slot-definition-name slot)) (boundp (swank-mop:slot-boundp-using-class class object slot))) `(,@(if boundp - `((:value ,(swank-mop:slot-value-using-class class object slot))) + `((:value ,(swank-mop:slot-value-using-class class object slot) + ,(print-slot-for-emacs class object slot))) `("#<unbound>")) " " (:action "[set value]"

1 0

[slime-devel] giving reasons for RPC aborts
by Taylor R Campbell 29 Jun '07

29 Jun '07

(I asked about this a year ago, but must have forgotten about it.) There are many cases where a user invoked a command that doesn't make any sense, so the RPC can't complete with a meaningful answer, but it would also be overkill to throw the user into a debugger. It would be nice to abort the RPC with a message to the user, such as `Package does not exist' for `slime-repl-set-package' or `Undefined function' for `slime-disassemble-symbol'. It looks like there was once a time when a message could be supplied with a :ABORT result from an RPC, and there are some vestigial remnants of support for it -- `slime-rex' forms with (:ABORT &OPTIONAL REASON), and indeed the documentation of `slime-rex' says that the reason is not optinoal --, but there are many other uses that prohibit a reason from being supplied. Is there a good reason for :ABORT responses not to have an optional message associated with them, or would a patch be welcomed for all of the uses of `slime-rex' to consistently accept an optional message?

3 5

[slime-devel] Daily ChangeLog diff
by mbaringer＠common-lisp.net 29 Jun '07

29 Jun '07

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1138 slime/ChangeLog:1.1139 --- slime/ChangeLog:1.1138 Wed Jun 27 11:53:44 2007 +++ slime/ChangeLog Thu Jun 28 08:27:51 2007 @@ -1,3 +1,11 @@ +2007-06-28 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (def-slime-selector-method): Revert Marco's change from + 2007-05-23. BODY can return a buffer name, like "*slime-events*". + Handle that and never ignore invalid return values. Force BODY to + abort if there's no suitable buffer. Why would you want to switch + buffers if the desired buffer doesn't exist? + 2007-06-27 Tobias C. Rittweiler <tcr(a)freebits.de> Fixing `C-c M-q' at the REPL. Thanks to André Thieme for pointing

1 0

[slime-devel] Control up-arrow broken?
by Shane Hoversten 28 Jun '07

28 Jun '07

Hi - In Slime 2.0, if you're in the REPL and you type the beginning of a form, and then control up-arrow, you iterate through forms that match the portion of the form that you've typed so far. In CVS Slime this no longer works. (I don't know when it stopped working.) To illustrate, in Slime 2.0 if you typed: CL-USER> (blah 'hi 2 3 4) CL-USER> (monkey 10 10 10) and then CL-USER> (bl[control up-arrow] Slime would offer up the (blah ...) form. Now, it offers up the last form typed, the (monkey ...) form. Perhaps this was a purposeful change? (Although I don't know who wouldn't want the 2.0 behavior.) If so, is there any way to get the 2.0 behavior back? If it was NOT a purposeful change, I'm surprised that I'm the only person who's noticed this - I use this feature all the time, and assumed others did, too. Comments? Shane

2 1

[slime-devel] Daily ChangeLog diff
by mbaringer＠common-lisp.net 28 Jun '07

28 Jun '07

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1137 slime/ChangeLog:1.1138 --- slime/ChangeLog:1.1137 Sat Jun 16 07:37:36 2007 +++ slime/ChangeLog Wed Jun 27 11:53:44 2007 @@ -1,3 +1,12 @@ +2007-06-27 Tobias C. Rittweiler <tcr(a)freebits.de> + + Fixing `C-c M-q' at the REPL. Thanks to André Thieme for pointing + out that it has been broken since several months. + + * slime.el (slime-reindent-defun): Use functions + `slime-beginning-of-defun' and `slime-end-of-defun' that were + introduced in the last changeset. + 2007-06-16 Tobias C. Rittweiler <tcr(a)freebits.de> * slime.el: Pressing `C-M-a' (beginning-of-defun) in midst of the

1 0

[slime-devel] send-repl-results-to-emacs and slime-repl-insert-result.
by Vladimir Sedach 20 Jun '07

20 Jun '07

Hello, In recent (or maybe not so recent) changes to swank.lisp, send-repl-results-to-emacs sends a :write-string back to the slime dispatcher instead of :return or :emacs-rex or whatever it was previously. This means that slime-repl-eval-string never gets an :ok result back, so the result printing code in slime-repl-insert-result is of superfluous now (and can be deleted, but don't do that yet!). There must be a good reason for this change, however I think it is worthwhile to restore that functionality so slime-repl-insert-result can be used as a target for defadvice for getting meaningful results (including multiple values, which putting advice around slime-write-string would not accomplish, besides being more complicated) back from REPL interactions. In particular, I want to slap defadvice before it to resurrect my repl-interaction-to-unit test code (http://common-lisp.net/pipermail/slime-devel/2006-September/005241.html) What does everyone think, and what would be the issues to changing send-repl-results-to-emacs back? Vladimir

3 4

[slime-devel] non-interactive interaction with repl
by Joe Corneli 19 Jun '07

19 Jun '07

I see how I can non-interactively feed the REPL, by using `slime-repl-eval-string' -- e.g. -- (slime-repl-eval-string "*package*") However, I don't see how to get the back into Emacs in a straightforward way. Whereas the above command prints the current package in the REPL buffer, I desire a command that returns the current package to Emacs. (slime-eval (+ 1 2)) returns 3. (slime-eval '*package*) triggers SLDB with the error The variable SWANK-IO-PACKAGE::*PACKAGE* is unbound. [Condition of type UNBOUND-VARIABLE]

2 2

[slime-devel] fix for the autodoc & typeout error for functions containing #\% in the name.
by Evrim Ulu 18 Jun '07

18 Jun '07

Hi, I've been using slime and the autodoc feature fails to execute for fun's having #\% char in the name. That's due to elisp's format string. I'm attaching the slime.el diff. Actually this patch is nothing more than a hack, i've catched the error condition and made it work until somebody pushes a real fix. evrim. Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.728 diff -r1.728 slime.el 5944c5944,5946 < (insert (apply #'format format-string format-args)))) --- > (insert (condition-case err > (apply #'format format-string format-args) > (error (format "%s" format-string))))))

1 0

[slime-devel] Daily ChangeLog diff
by mbaringer＠common-lisp.net 17 Jun '07

17 Jun '07

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1136 slime/ChangeLog:1.1137 --- slime/ChangeLog:1.1136 Thu May 24 15:23:24 2007 +++ slime/ChangeLog Sat Jun 16 07:37:36 2007 @@ -1,3 +1,32 @@ +2007-06-16 Tobias C. Rittweiler <tcr(a)freebits.de> + + * slime.el: Pressing `C-M-a' (beginning-of-defun) in midst of the + last REPL prompt directs the cursor to the beginning of the + prompt. Pressing it again, would do nothing; now it moves the + cursor to the start of the previous prompt (as it's consistent + with the behaviour when the cursor was placed midst one of the old + prompts.) + + Likewise for `C-M-e' (end-of-defun) + + Additionally fixing `C-c C-s' (slime-complete-form) at the REPL. + + (slime-keys): New bindings for `C-M-a' and `C-M-e' to + SLIME-BEGINNING-OF-DEFUN and SLIME-END-OF-DEFUN respectively. + (slime-keys): Making `C-c C-q' (slime-close-parens-at-point) + obsolete, as it didn't work correctly on the REPL. + (slime-repl-mode-map): Removed bindings for `C-M-a' and `C-M-e', + as they're now inherited from SLIME-KEYS. + (slime-repl-beginning-of-defun, slime-repl-end-of-defun): Jump to + the previous (next) prompt if called twice in a row. + + (slime-close-parens-at-point): Commented out. + (slime-close-all-sexp): Renamed to SLIME-CLOSE-ALL-PARENS-IN-SEXP. + (slime-close-all-parens-in-sexp): Modified to take + SLIME-CLOSE-PARENS-LIMIT into account. + (slime-complete-form): Use SLIME-CLOSE-ALL-PARENS-IN-SEXP. + + 2007-05-24 Tobias C. Rittweiler <tcr(a)freebits.de> * swank.lisp: Fixed regression in completion: "swank[TAB]" would

1 0

[slime-devel] syntax highlighting and comments using the #| |# reader syntax
by Evan Monroig 15 Jun '07

15 Jun '07

Hi, When I insert multiple region comments using the #| |# reader syntax, some of the code between the comments becomes highlighted as if it were part of the comments. For example, in the blurb below, the third "defun" form is displayed as a comment. Is this normal behavior? Thanks in advance, Evan ---- (defun test () nil) #| comment |# (defun test () nil) #| comment #| (defun test () nil) ----

6 9