slime-devel March 2005

slime-devel@common-lisp.net

36 participants
61 discussions

[slime-devel] comma shortcut doesn't work always
by Edi Weitz 31 Jan '06

31 Jan '06

Another minor glitch that I encountered is that the comma shortcut in the REPL doesn't always work. I can consistently reproduce it (GNU Emacs 21.3.50 and also 21.3 release) like this: 1. Make sure point is at the beginning of a REPL input line. 2. Split Emacs frame into two windows, one of them being the REPL the other one containing something else. 3. Hide REPL window with C-x 0. 4. Now type M-x slime. 5. Type the comma. At this point I'm not asked for a shortcut command in the minibuffer but the comma is simply entered into the REPL instead. Anybody else seeing this? Cheers, Edi.

10 25

Re: [slime-devel] Re: CLISP SLIME implementation breaks in CVS
by Bill_Clementson＠peoplesoft.com 21 Jan '06

21 Jan '06

Luke Gorrie <luke(a)bluetail.com> writes: > Bill_Clementson(a)peoplesoft.com writes: > > > My previous SLIME installation was a CVS install from 4/18. I've just taken > > the latest CVS install and the CLISP SLIME implementation (under Windows) > > breaks. Here is the error: > > > > COERCE: #<MACRO #<COMPILED-CLOSURE SWANK::DEFSLIMEFUN>> cannot be coerced > > to type FUNCTION > > [Condition of type SIMPLE-TYPE-ERROR] > > I can reproduce this but I've no idea what is causing it. It /looks/ > like someone is trying to call defslimefun as a function rather than a > macro, but I don't see where it could happen -- the macro is declared > at the top of the only file that refers to it. > > I did fix a different but similar problem that I got under CLISP. It > seems like I had to swap the order of a couple of macros, one of which > expanded into into code that calls the other, but that surely can't be > the reason. > > > Backtrace: > > 0: EVAL frame for form (SWANK:CREATE-SWANK-SERVER 4007) > > Mine actually gives an empty backtrace (!). I fixed the Elisp-side to > handle that incase it helps someone more CLISP-savvy find the problem. Has anybody had any luck in finding the source of this problem? CLISP still breaks for me in the latest CVS. I have had a look at all of the DEFSLIMEFUN's that were modified since 4/18 (the previous CVS version that I had which was working ok with CLISP) and haven't found any obvious clues. Any suggestions on how I might debug this issue as it occurs at startup during the slime-connect processing in Emacs (after CLISP has started up successfully)? - Bill

5 6

[slime-devel] Comment indentation in newer Emacsen
by Edi Weitz 03 Jul '05

03 Jul '05

Dumb question number two for today: I've recently switched to a CVS build (circa end of January) of GNU Emacs on Windows. Now, if I have a function like this in a lisp mode buffer (defun foo () "This is a very very very very very very very very very very very very long comment line." (bar x)) and press M-q within the comment string the result looks like so: (defun foo () "This is a very very very very very very very very very very very very long comment line." (bar x)) However, in 21.3 the result looked like this (defun foo () "This is a very very very very very very very very very very very very long comment line." (bar x)) which is what I prefer. Is this a bug or can the behaviour be changed with some setting that I'm missing? Thanks, Edi.

3 3

[slime-devel] [Patch] Improve slime-edit-definition-other-window and ...-frame
by Matthias Koeppe 01 Apr '05

01 Apr '05

Hi, I am sending a little patch that improves the commands slime-edit-definition-other-window and ...-frame. Would someone like to merge it into CVS? Cheers, Matthias 2005-03-27 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> * slime.el (slime-keys): Bind slime-edit-definition-other-window to `C-x 4 .' and slime-edit-definition-other-frame to `C-x 5 .', shadowing the equivalent find-tag... bindings. (slime-goto-definition-other-window-aux): New function, adapted from the Emacs function find-tag-other-window. (slime-goto-definition): In the other-window and other-frame cases, make sure point does not move in the originating window, even when the definition is found in the same buffer. --- slime.el.~1.473.~ 2005-03-27 16:35:04.000000000 +0200 +++ slime.el 2005-03-27 17:02:06.000000000 +0200 @@ -555,6 +555,8 @@ ("\C-i" slime-complete-symbol :prefixed t :inferior t) ("\M-i" slime-fuzzy-complete-symbol :prefixed t :inferior t) ("\M-." slime-edit-definition :inferior t :sldb t) + ("\C-x4." slime-edit-definition-other-window :inferior t :sldb t) + ("\C-x5." slime-edit-definition-other-frame :inferior t :sldb t) ("\M-," slime-pop-find-definition-stack :inferior t :sldb t) ("\M-*" slime-pop-find-definition-stack :inferior t :sldb t) ("\C-q" slime-close-parens-at-point :prefixed t :inferior t) @@ -5122,18 +5124,41 @@ (error "No known definition for: %s" name)) (slime-goto-definition name definitions where)))) +(defun slime-goto-definition-other-window-aux (definition) + ;; Taken from the Emacs function `find-tag-other-window': + ;; This hair is to deal with the case where the tag is found in the + ;; selected window's buffer; without the hair, point is moved in both + ;; windows. To prevent this, we save the selected window's point before + ;; doing find-tag-noselect, and restore it after. + (let ((window-point (window-point (selected-window)))) + (slime-goto-source-location (slime-definition.location + definition)) + (let ((tagbuf (current-buffer)) + (tagpoint (point))) + (set-window-point (prog1 + (selected-window) + (switch-to-buffer-other-window tagbuf) + ;; We have to set this new window's point; it + ;; might already have been displaying a + ;; different portion of tagbuf, in which case + ;; switch-to-buffer-other-window doesn't set + ;; the window's point from the buffer. + (set-window-point (selected-window) tagpoint)) + window-point)))) + (defun slime-goto-definition (name definitions &optional where) (slime-push-definition-stack) (cond ((slime-length> definitions 1) (slime-show-definitions name definitions)) (t - (slime-goto-source-location (slime-definition.location - (car definitions))) (cond ((equal where 'window) - (switch-to-buffer-other-window (current-buffer))) + (slime-goto-definition-other-window-aux (car definitions))) ((equal where 'frame) - (switch-to-buffer-other-frame (current-buffer))) + (let ((pop-up-frames t)) + (slime-goto-definition-other-window-aux (car definitions)))) (t + (slime-goto-source-location (slime-definition.location + (car definitions))) (switch-to-buffer (current-buffer))))))) (defun slime-edit-definition-other-window (name) -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe

2 6

[slime-devel] Problems with LWW FLI
by Edi Weitz 29 Mar '05

29 Mar '05

Hi! Has anyone else problems with SLIME when using Lispworks on Windows (XP) and its FLI? I've run into a (reproducable but complicated) situation where SLIME simply hung while there were no problems from the LW IDE or from the command line. I'm sitting at my Linux laptop now but I can try to create a simple test case - I just wanted to check if this is a known problem. Cheers, Edi.

4 11

[slime-devel] Class browser: how does it work? [was: Re: [slime-cvs] CVS update: slime/NEWS]
by Paolo Amoroso 29 Mar '05

29 Mar '05

heller(a)common-lisp.net (Helmut Eller) writes: > Modified Files: > NEWS [...] > +* 1.2 (March 2005) [...] > +** M-x slime-browse-classes > +A simple class browser was added. How does it work? I have tried invoking it in a CMUCL SLIME session with McCLIM loaded, passing clim-clx::clx-medium as an argument. I get a buffer containing: Class Browser [+] clim-clx::clx-medium If I hit ENTER on "+", it turns into "X" and nothing else happens. Apparently, any other keystroke displays this error in the echo area: Text is read only: "Attempt to change text outside editable field" I use the latest SLIME and McCLIM CVS sources, CMUCL Snapshot 2005-03 and GNU Emacs 21.3.2 under Slackware Linux 10.0. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

2 3

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 27 Mar '05

27 Mar '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.649 slime/ChangeLog:1.651 --- slime/ChangeLog:1.649 Wed Mar 23 13:23:26 2005 +++ slime/ChangeLog Sun Mar 27 21:42:54 2005 @@ -1,3 +1,13 @@ +2005-03-27 Helmut Eller <heller(a)common-lisp.net> + + * PROBLEMS, NEWS, doc/slime.texi: Some updates for the upcoming + release. + +2005-03-27 Russell McManus <russell_mcmanus(a)yahoo.com> + + * swank-clisp.lisp (getpid): Try sys::process-id if + sys::program-id doesn't exist. + 2005-03-23 Marco Baringer <mb(a)bese.it> * swank.lisp (commit-edited-value): Read a backquated string,

1 0

[slime-devel] small patch for cvs head clisp (backward compatible)
by Russell McManus 27 Mar '05

27 Mar '05

diff -c -r1.45 swank-clisp.lisp *** swank-clisp.lisp 15 Dec 2004 22:35:20 -0000 1.45 --- swank-clisp.lisp 26 Mar 2005 02:15:23 -0000 *************** *** 81,88 **** (funcall fn)) #+unix ! (defmethod getpid () ! (system::program-id)) #+win32 (defmethod getpid () (cond ((find-package :win32) --- 81,90 ---- (funcall fn)) #+unix ! (defmethod getpid () ! (funcall (or (find-symbol "PROGRAM-ID" :system) ! (find-symbol "PROCESS-ID" :system) ! (error "getpid not implemented")))) #+win32 (defmethod getpid () (cond ((find-package :win32) ----------

2 1

[slime-devel] problems with slime CVS and xemacs 21.4.15
by Nathan Froyd 27 Mar '05

27 Mar '05

I think this is really an Emacs problem, but Slime is the first Emacs package I've used where problems like this have come up, so I'm asking here first. I'm running XEmacs 21.4.15 on OS X 10.3.8. I just updated my Slime to the newest, shiniest CVS version (from 1.0 or so), only to find out that it won't work with my XEmacs. Near as I can tell, it's because my XEmacs isn't MULE-ized ({make,find}-coding-system do not exist) and Slime really wants MULE or some semblance thereof to operate. I assume then that Slime does not support non-MULE emacsen...is this a correct assumption? Or do I just need a newer XEmacs that features (some) support for coding systems in non-MULE builds? I see from looking at the archives that people seem to be using Slime CVS in XEmacs, but it's not clear whether those are MULE builds or not. Thanks, -- Nathan | From Man's effeminate slackness it begins. --Paradise Lost

2 1

[slime-devel] Slime pre-port
by Juan Jose Garcia Ripoll 24 Mar '05

24 Mar '05

Hi, since the latest release, Slime seems to have moved quite fast and requires quite advanced MOP features (namely, functions for querying method keywords, COMPUTE-APPLICABLE-METHODS-USING-CLASSES, etc). Until I fixed this, I have put a zip file with my previous attempt at a port of Slime http://ecls.sf.net/slime-patches.zip Even though it says "patches" it is a full slime distribution. I just preserved the name to overwrite a previous, incomplete zip file. Regards, Juanjo

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel March 2005