slime-devel

slime-devel@common-lisp.net

4231 discussions

[slime-devel] wrapping a non-LISP prompt for use by SLIME
by Joe Corneli 30 Apr '07

30 Apr '07

Hi, I have been contributing some work to the Monster Mountain project, http://code.google.com/p/mmtn/ -- which is nominally a Lisp-based MUD, but is, more generally, a Lisp-based application server. One of the things that it currently features is a "multi-user Lisp", with login via netcat. In particular, it largely solves a problem I had brought up on this mailing list in 2006 -- http://common-lisp.net/pipermail/slime-devel/2006-June/005033.html I am now curious about what I think should be a rather simple problem, which is, providing a SLIME connection to this prompt. Schematically, what I envision is: remote server -runs-> LISP 1 LISP 1 -runs-> Monster Mountain remote server -runs-> LISP 2 LISP 2 -runs-> SWANK local Emacs -`slime-connect's over SSH tunnel to-> SWANK SWANK-embedded LISP process -logs in to-> Monster Mountain Result: SLIME interface to Monster Mountain. This looks complicated, but my sense is that it should "just work" if Monster Mountain can provide the "SWANK-embedded LISP process" with the right stuff. I will probably have to ask some additional questions (probably not here) to figure out how to get LISP to connect to Monster Mountain (as above, currently that is done in the shell with netcat), but for this list my question is: what should the interface of the Monster Mountain server look like to its LISP client in order for SLIME to be happy? (My intuition is that it should roughly look like we are in a "virtual package", whatever that would mean.)

1 0

[slime-devel] RFC for completion behaviour
by Tobias C. Rittweiler 28 Apr '07

28 Apr '07

Hi Slime-hackers, Two issues related to how completion should behave: a) As of now, completing on "asdf::" or "asdf::foo" means that it's tried to find any (or the respective) symbols within #<PACKAGE "ASDF"> that is _accessible_. However, this includes all those symbols that are inherited from other packages, including :CL, as most packages include it. If you're looking for a symbol that you know is _internal_ to some package, you're forced to search through (possibly) quite a mess. So what do you think, to change the completion code to only try to match against symbols _internal_ to #<PACKAGE "ASDF"> in the above case? The downside is that if you've got a package :A that uses some internal packages :B and :C for internal code structure purpose, you won't be able to find the symbols in these internal packages. So if people want the new bevahiour, I'd implement it in a way that is has to be explicitely enabled by setting some global value. What's your opinion on this? b) Slime's standard completion function `SLIME-COMPLETE-SYMBOL*' (i.e. the one that is used at the REPL, for instance) completes "asdf:*Com" to "asdf:*COMPILE-FILE--BEHAVIOUR*", where point is at the end of the completion. (As opposed to `SLIME-SIMPLE-COMPLETE-SYMBOL', which would complete it to "asdf:*COMPILE-FILE-".) Traditionally, the point has been set to the place between the two dashes ("asdf:*COMPILE-FILE-|-BEHAVIOUR*", where "|" is supposed to mean the cursor.) It doesn't anymore, rendering that kind of completion pretty much b0rked. I'd like to restore the traditional behaviour. Comments? -T.

7 13

[slime-devel] slime-complete-form extra parenthesis
by Mac Chan 27 Apr '07

27 Apr '07

I use slime-complete-form a lot. However, like many who uses slime, I also have paredit-mode enabled. Is there a way to instruct slime-complete-form not to insert extra close parenthesis at the end? (with-open-file _) => C-c C-s slime-complete-form => (with-open-file _(stream filespec :direction direction :element-type element-type :if-exists if-exists :if-does-not-exist if-does-not-exist :external-format external-format) body...)) ;; <-- extra ) Thanks, -- Mac

1 0

[slime-devel] Inserting eval results in the current buffer
by Nikodemus Siivola 27 Apr '07

27 Apr '07

I submit that the current behaviour of <prefix> C-x C-e is not very useful. It is probably almost ideal for <prefix> C-c : -- eg. for creating constants with one-liners. This is what I use in lieu of it, and what might be good for Slime proper too. (defun ns:scan-forward (stop-after stop-before) (do () ((or (eql (char-after) stop-before) (eql (char-before) stop-after))) (forward-char))) (defun ns:comment-at-eol () (let ((newline (string-to-char "\n")) (comment (string-to-char ";"))) (ns:scan-forward comment newline) (unless (eql newline (char-after)) (kill-line)) (unless (eql comment (char-before)) (insert " ;"))) (insert " ")) (defun ns:eval-in-lisp-insert-comment () (interactive) (lexical-let ((current-buffer (current-buffer))) (slime-eval-with-transcript `(swank:interactive-eval ,(slime-last-expression)) `(lambda (value) (with-current-buffer ,current-buffer (ns:comment-at-eol) (insert (format "%s" value))))))) Cheers, -- Nikodemus

1 0

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

23 Apr '07

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1116 slime/ChangeLog:1.1117 --- slime/ChangeLog:1.1116 Thu Apr 19 12:32:20 2007 +++ slime/ChangeLog Mon Apr 23 13:10:12 2007 @@ -1,4 +1,4 @@ -2007-04-19 Tobias C. Rittweiler <INSERT-EMAIL-HERE> +2007-04-19 Tobias C. Rittweiler <tcr(a)freebits.de> * swank-backend.lisp (label-value-line): Add :newline as &key argument; if true (the default) inserts a newline.

1 0

[slime-devel] Coding issue
by Mikhail Shevchuk 23 Apr '07

23 Apr '07

Hi, I have a little socket application in AllegroCL, that should send utf-8-encoded strings. I've tested it in standalone alisp and that works fine - server receives them correct. But when I use mighty SLIME, I get '???' instead of my strings. I've set the following variables: ~/.emacs (setq slime-net-coding-system 'utf-8-unix) and ~/.swank.lisp (setq SWANK::*CODING-SYSTEM* ':utf-8-unix) But obviously that doesn't works. I've also checked that these variables were correctly set up: C-h v tells that: slime-net-coding-system is a variable defined in `slime.el'. Its value is utf-8-unix CL-USER> SWANK::*coding-system* :UTF-8-UNIX Thanks. -- A vivid and creative mind characterizes you.

1 0

[slime-devel] SLIME on JEDit
by Sean Charles 23 Apr '07

23 Apr '07

Forgot Armed Bear too, could that be a runner! :-)

1 0

[slime-devel] SLIME to JEdit???
by Sean Charles 23 Apr '07

23 Apr '07

OK, here's a thought... ...I like Emacs+Slime but I also like Jedit. I use JScheme a lot and it's nice to be in a 'Java bucket' running JScheme. Given the existence of Linj, does anybody think it'd be up for porting the SLIME code base, or the minimum working set required to support Jedit, using Linj to convert the slime code into Java... presumably only the client side code would be required. Sadly I do not have the necessary experience with the code base to even begin thinking about starting something like this. It'd be very interesting to see how far Linj could get things 'for free' as it where. LINJ: (http://www.evaluator.pt/download.html) I also use SchemeWay with Eclipse because it is the only alternative to SLIME+Emacs for my SISCWeb stuff. Thanks Sean Charles.

1 0

[slime-devel] REPL results and output
by Madhu 22 Apr '07

22 Apr '07

The printing of repl results seems to have changed recently: CL-USER> (format *standard-output* "foo") NIL CL-USER> foo CL-USER> (format *standard-output* "foo~%") NIL CL-USER> foo i.e. The result is printed and the prompt is printed before the command's output. Do other people get this same behaviour? Is this backend/interaction mode specific? (I'm using cmucl). -- Madhu

4 6

[slime-devel] [PATCH] fix apropos wrt external symbols
by Tobias C. Rittweiler 21 Apr '07

21 Apr '07

2007-04-22 Tobias C. Rittweiler <...> * swank.lisp: Previously when using SLIME-APROPOS-PACKAGE, only those symbols were considered if their home package matched the given package; this would, however, prevent all those symbols from being listed that are imported from another package, and then exported again in the package they got imported into. (As an example, SWANK:RESTART-FRAME is actually from SWANK-BACKEND.) (apropos-matcher): Renamed to MAKE-REGEXP-MATCHER. (make-regexp-matcher): Changed to only match for a given regexp. (apropos-symbols): Use MAKE-REGEXP-MATCHER.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel