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

[patch] calling slime-edit-definition in the first position of a *slime-apropos* buffer
by João Távora 08 Apr '15

08 Apr '15

Here is a fix for an annoyance similar to the one I described in my previous email: Pressing M-. on the first position of the *slime-apropos* raises a "args out of range error". Marco, I'm cc'ing you, since I believe the error stems from the interaction of your `slime-fancy-inspector' contrib with `slime-inspector-property-at-point'. It could be a easy fix in slime.el diff --git a/slime.el b/slime.el index 106b0fa..857e68f 100644 --- a/slime.el +++ b/slime.el @@ -6636,7 +6636,8 @@ position of point in the current buffer." when value return (list property value))))) (or (funcall find-property (point)) - (funcall find-property (1- (point)))))) + (and (> (point) (point-min)) + (funcall find-property (1- (point))))))) (defun slime-inspector-operate-on-point () "Invoke the command for the text at point. But the real problem is that `slime-fancy-inspector' contrib places its `slime-edit-inspector-part' in `slime-edit-definition-hooks', thus causing `slime-inspector-operate-on-point' to be called uselessly in non-inspector contexts. So maybe there's a better fix within the spirit of `slime-edit-definition-hooks' diff --git a/contrib/slime-fancy-inspector.el b/contrib/slime-fancy-inspector.el index 8918f90..bef8d1c 100644 --- a/contrib/slime-fancy-inspector.el +++ b/contrib/slime-fancy-inspector.el @@ -22,6 +22,7 @@ ,(slime-definition-at-point t)))) (defun slime-edit-inspector-part (name &optional where) + (and (eq major-mode 'slime-inspector-mode) (destructuring-bind (&optional property value) (slime-inspector-property-at-point) (when (eq property 'slime-part-number) @@ -34,6 +35,6 @@ (list (make-slime-xref :dspec `(,name) :location location)) name - where)))))) + where))))))) -- João Távora

1 0

Raising the Emacs frame when ed/debugger/inspector pop up
by Luís Oliveira 08 Apr '15

08 Apr '15

Hello, When developing GUI applications, I find it essential to have the Emacs frame pop up when my application signals an unhandled error. The problem is that the debugger will often pop up while I'm interacting with the application (and Emacs is usually hidden somewhere beneath it), so I would often be left staring at a frozen GUI not understanding what was happening. This pull request <https://github.com/slime/slime/pull/92> makes the frame raise. It also does the same thing when entering `slime-ed' and `slime-open-inspector' for similar reasons. In my particular case, sometimes those events come from the application GUI, sometimes from the Allegro CL IDE. I have two questions for my fellow SLIME users: 1. is there any situation where this behaviour would be undesirable? 2. if so, we need a customisation variable. Which behaviour should be the default one? Thanks, Luís

3 7

New contrib: slime-fancy-trace
by Luís Oliveira 08 Apr '15

08 Apr '15

Hello, The attached patch implements a new contrib that rebinds C-c C-t to an alternative implementation of slime-toggle-trace-fdefinition that takes advantage of the slime-parse contrib. With this contrib loaded, C-u C-t is able to trace methods, setf functions, local functions, etc, when supported by the SWANK backend. Cheers, -- Luís Oliveira http://r42.eu/~luis/

3 2

indent based on subsequence of symbol
by Lucien Pullen 08 Apr '15

08 Apr '15

I was wondering if it is possible to specify indentation rules for all symbols that match a substring. I have a macro that creates implicit MACROLET bodies for symbols starting with "X!" (like DEFMACRO! from Let Over Lambda), and I'd like them to be indented as LAMBDA. So, something like: (defun/xml (item) (x!xsl/output (:method "xml")) (x!xsl/match (:name item) (x!name () (x!xsl/value-of (:select "name"))))) Currently with slime-indentation, it gets indented as such: (defun/xml (item) (x!xsl/output (:method "xml")) (x!xsl/match (:name item) (x!name () (x!xsl/value-of (:select "name"))))) The names of symbols will not be known beforehand, just that they start with "X!".

2 7

error in process filter: Keyword argument :coding-system not one of (:coding-systems)
by Thorsten Jolitz 08 Apr '15

08 Apr '15

(does my message comes through this time? I tried before ...) Hi List, I continue to get this error ,-------------------------------------------------------------------- | error in process filter: Keyword argument :coding-system not one of | (:coding-systems) `-------------------------------------------------------------------- when calling Slime with a PicoLisp swank implementation, besides having changed the :encoding to what I believe is a valid value. original version: ,-------------------------------------------------------------------- | (de swank:connection-info () | (list | ':pid *Pid | ':style 'nil | ':encoding '(:coding-system "utf-8" :external-format "utf-8") [...] `-------------------------------------------------------------------- changed to new version: ,------------------------------------------------ | (de swank:connection-info () | (list | ':pid *Pid | ':style 'nil | ':encoding '(:coding-system "utf-8-unix") [...] `------------------------------------------------ What am I missing here? PS I just recently cloned the newest slime from the 'unofficial' github repo. -- cheers, Thorsten

2 1

slime tests
by Paul Bowyer 08 Apr '15

08 Apr '15

Hello João, I tried to run the slime test suite this morning to see what results it produced. I'm uncertain what the proper procedure is for running the test suite, but this is what I did. I made the test suite available by including "slime-tests" in my ".emacs" file in the (slime-setup '( < other contribs > slime-tests)), which seemed to work. I started emacs, did M-x slime, then did M-x slime-batch-test, which ran the test suite after asking me if I wanted to start a second inferior lisp (I tried it with and without). The results came out with 17 unexpected failures and I have attached a file "slime-batch-test-results.txt" which contains the contents of the *ert* buffer from emacs. For reference, I'm running Linux Mint 14 with KDE-4.9.5 and sbcl-1.1.14 and emacs-23.4.1. Am I using the proper procedure to run the slime test suite? In the past when I ran the test suite, it generally finished with only one/(1) expected failure and no/(0) unexpected failures. Should I expect more failures in the slime test suite with the github version of slime? Thanks, Paul Bowyer

3 3

autodoc bugs
by Nick Levine 08 Apr '15

08 Apr '15

I've reported a couple of autodoc bugs, at https://bugs.launchpad.net/slime. The first of these was four months ago. Is anyone tracking these? Is autodoc actively maintained? Thanks. - nick

2 2

Maybe another glitch
by Paul Bowyer 08 Apr '15

08 Apr '15

Hello João, I've been using github slime continuously for a few days and everything I normally use seems to be working fine, but today I tried to use multiple REPLs by loading slime-mrepl in my .emacs file, which is available in the contrib folder. When I do M-x slime-open-listener as the documentation indicates, I get [No match] as a response. Is there another way to get multiple REPLs in different threads? I was hoping to try this feature because I have a client / server app I want to test by running the server from one REPL and the client from the second REPL, but I can't do it in slime without slime-mrepl working. Also, as I was scouring the slime html documentation looking for clues about multiple REPLs I noticed several sections where the text was single-columned, which didn't look very readable. The sections I noticed where this occurred were: 2.5.2 Multiple Lisps. 3.1.4 Key bindings 3.2 Evaluation commands 3.3 Compilation commands . . . Seems to continue on this way... I create the html file by using 'make slime.html' in the slime/doc folder and this is what it produces. Thanks, Paul Bowyer

2 7

Warnings and compile failures
by Zach 08 Apr '15

08 Apr '15

List, It seems that when Slime encounters a warning during compilation, it reports the compilation as a failed and the defuns are not updated. Is there a way to disable this for decidedly benign warnings? If you care for context, Iterate warns if you include some code that it cannot walk. I want to iterate over something wrapped in a without-interrupts environment (some C code, which doesn't handle interruptions well). Without-interrupts, in SBCL, uses a macrolet environment which is one of the things that the Iterate code walker doesn't know how to walk. That said, the inability to walk the code in no way affects the execution unless there are forms in the unwalkable code that are Iterate directives (or whatever you want to call them). This means that so long as there Slime aborts compilation upon any warning, any code with a macrolet inside an Iterate is more difficult than than it needs to be when compiling from a buffer in Slime. I am now wrapping the offending macrolet code in another function call so Iterate doesn't know about it and doesn't complain, but it would be nice if these kinds of work-arounds weren't necessary. Thanks, Zach KS

3 2

Slime not connecting to swank socket
by Dana Wheeler 08 Apr '15

08 Apr '15

When starting slime with "M-x slime" a window is created and displays the *inferior-lisp* process with the message: (progn (load "/Users/Dana/slime/swank-loader.lisp" :verbose t) (funcall (read-from-string "swank-loader:init")) (funcall (read-from-string "swank:start-server") "/var/folders/gq/3hr2_3j961d6rsz4dm8x83ch0000gq/T/slime.2310")) and polls ... forever. Enmap 127.0.0.1 shows 4005/tcp open pxc-pin so swank appears to be working and has opened the proper port but ls /var/folders/gq/<gobbldee-goop>/T shows no file "slime.2310". I am assuming that slime made a request to the system for a virtual file interface to the port 127.0.0.1:4005 and that request failed either on the slime end or the system end. Setting M-x toggle-debug-on-error produces no information as apparently emacs hasn't detected an error. The slime portion of my configuration is ;; *************************** Activate SLIME for Clozure ******************************* (add-to-list 'load-path "/Users/Dana/slime/") ; your SLIME directory (setq inferior-lisp-program "/Applications/ClozureCL.app/Contents/MacOS/dx86cl64 -K utf-8") (require 'slime) (slime-setup) Any suggestions on how to debug this would be greatly appreciated. Software: OS X 10.7.5 Clozure 1.8.1 (15418) Emacs 24.3 (9.0) Slime cvs version downloaded 2013-09-14 Thanks Dana S. Wheeler dswheeler777.at.gmail.com

2 2