Hiya,
Here are three small patches for SLIME. They do the following:
1. Make find-definitions a little more flexible with an around method: if the symbol isn't in the current package, the around method goes on to look in all the packages too. (I haven't added similar logic to symbol completion but will someday).
2. Modifies swank-loader so that Allegro's alisp and mlisp programs get different locations. Otherwise mlisp complains about alisp's files.
3. Added two more symbols to the exports list in swank-openmcl.
HTH,
Index: swank-backend.lisp
RCS file: /project/slime/cvsroot/slime/swank-backend.lisp,v retrieving revision 1.94 diff -u -w -r1.94 swank-backend.lisp --- swank-backend.lisp 20 Nov 2005 23:25:38 -0000 1.94 +++ swank-backend.lisp 16 Mar 2006 01:04:37 -0000 @@ -615,6 +615,20 @@ LOCATION is the source location for the definition.") +(defvar *currently-finding-definitions* nil)
+(defmethod find-definitions :around ((name symbol))
- ;; look in other packages if we don't find something in this
package
- (let ((result (call-next-method)))
- (unless (or result *currently-finding-definitions*)
(let ((*currently-finding-definitions* t)(symbol-name (symbol-name name)))(dolist (package (list-all-packages))(let ((symbol (find-symbol symbol-name package)))(when symbol(setf result (append result (find-definitionssymbol))))))))
- result))
(definterface buffer-first-change (filename) "Called for effect the first time FILENAME's buffer is modified." (declare (ignore filename))
Index: swank-loader.lisp
RCS file: /project/slime/cvsroot/slime/swank-loader.lisp,v retrieving revision 1.55 diff -u -w -r1.55 swank-loader.lisp --- swank-loader.lisp 19 Jan 2006 22:56:16 -0000 1.55 +++ swank-loader.lisp 16 Mar 2006 01:04:38 -0000 @@ -65,7 +65,8 @@ ccl::*openmcl-major-version* ccl::*openmcl-minor-version*) #+lispworks (lisp-implementation-version)
- #+allegro excl::*common-lisp-version-number*
- #+allegro (concatenate 'string (if (eq 'h 'H) "A" "M") ;
ANSI vs MoDeRn
excl::*common-lisp-version-number*)
Index: swank-openmcl.lisp
RCS file: /project/slime/cvsroot/slime/swank-openmcl.lisp,v retrieving revision 1.103 diff -u -w -r1.103 swank-openmcl.lisp --- swank-openmcl.lisp 11 Nov 2005 23:43:43 -0000 1.103 +++ swank-openmcl.lisp 16 Mar 2006 01:04:38 -0000 @@ -65,6 +65,8 @@ cl:method cl:standard-class ccl::eql-specializer
- ccl::eql-specializer-object
- ccl::class-name ;; standard-class readers openmcl-mop:class-default-initargs openmcl-mop:class-direct-default-initargs
Gary King gwking@metabang.com writes:
Hiya,
Here are three small patches for SLIME. They do the following:
- Make find-definitions a little more flexible with an around
method: if the symbol isn't in the current package, the around method goes on to look in all the packages too. (I haven't added similar logic to symbol completion but will someday).
won't this make (find-definitions foo:test) returns definitions for bar:test as well? do we really want this?
- Modifies swank-loader so that Allegro's alisp and mlisp programs
get different locations. Otherwise mlisp complains about alisp's files.
applied. thanks.
- Added two more symbols to the exports list in swank-openmcl.
who uses these?
Hi,
On Mar 16, 2006, at 12:18 PM, Marco Baringer wrote:
- Make find-definitions a little more flexible with an around
method: if the symbol isn't in the current package, the around method goes on to look in all the packages too. (I haven't added similar logic to symbol completion but will someday).
won't this make (find-definitions foo:test) returns definitions for bar:test as well? do we really want this?
I may not have have been clear enough. Let me see if I do better with an example. Suppose i have two packages foo and bar and a function named test in each of them. Here are some scenarios:
* I am in package foo and search for test: the regular find- definitions finds the definition and I jump to foo::test directly. * I am in package bar and search for test. Again, I jump directly to bar::test. * I am in package xxx and search for test. This time, find- definitions finds nothing so it goes to the around method and finds two definitions and gives me the choices of foo::test and bar::test. * I am in package xxx and search for foo::test. Find-definitions finds the single definition, the around method is not used and i jump to foo::test. * I am in package bar and search for foo::test. results are as in package xxx. * I am in package xxx and search for foo:test (single #:). Neither the regular find-definitions nor the around method finds anything and i get the "no known definitions" message.
since the around method only fires if the regular finds nothing, it only changes behavior when the current symbol doesn't have a package prefix and isn't in the current package...
HTH,
On Mar 16, 2006, at 12:18 PM, Marco Baringer wrote:
- Added two more symbols to the exports list in swank-openmcl.
who uses these?
Agh. I do but I can't remember where <smile>. I'll try to figure that out.
* Marco Baringer [2006-03-16 18:18+0100] writes:
Gary King gwking@metabang.com writes:
Hiya,
Here are three small patches for SLIME. They do the following:
- Make find-definitions a little more flexible with an around
method: if the symbol isn't in the current package, the around method goes on to look in all the packages too. (I haven't added similar logic to symbol completion but will someday).
won't this make (find-definitions foo:test) returns definitions for bar:test as well? do we really want this?
No, at least not by default. "apropos" should be used to search similar symbols.
It might be useful though, to add a hook to find-definitions so that users can include whatever definitions they think are appropriate.
Helmut.
Hi Helmut,
won't this make (find-definitions foo:test) returns definitions for bar:test as well? do we really want this?
No, at least not by default. "apropos" should be used to search similar symbols.
I agree that we wouldn't want what Marco fears but that's not what the patch does. Since this is about finding definitions (not symbols) it doesn't seem to me that apropos is appropriate (so to speak <smile>).
It might be useful though, to add a hook to find-definitions so that users can include whatever definitions they think are appropriate.
Making things **simply** extensible is often a-good-thing (tm).
Has anyone actually tried the patch. FWIW, I find the behavior very intuitive (since it works the way meta-point does in MCL!).
What do other people do when they want to find a symbol in some other package? Do you always write out the package first?
thanks,
Gary King wrote:
Hiya,
Here are three small patches for SLIME. They do the following:
- Make find-definitions a little more flexible with an around method:
if the symbol isn't in the current package, the around method goes on to look in all the packages too. (I haven't added similar logic to symbol completion but will someday).
Is this an Allegro specific problem? This has been annoying me in both cases in recent weeks.
-M
Hi Mikel,
No, this is general slime feature / problem. I'd still like to know how people use meta-point in general? Do people expect to be in the correct package or specify the correct package every time?
On Mar 28, 2006, at 7:50 PM, Mikel Bancroft wrote:
Gary King wrote:
Hiya, Here are three small patches for SLIME. They do the following:
- Make find-definitions a little more flexible with an around
method: if the symbol isn't in the current package, the around method goes on to look in all the packages too. (I haven't added similar logic to symbol completion but will someday).
Is this an Allegro specific problem? This has been annoying me in both cases in recent weeks.
-M
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Gary King gwking@metabang.com writes:
No, this is general slime feature / problem. I'd still like to know how people use meta-point in general? Do people expect to be in the correct package or specify the correct package every time?
I would occasionally benefit from patch in cases when browsing a file whose code is in a package as-of-yet-unloaded, and meta-pointing to a symbol in COMMON-LISP, but that's about all: I virtually always work with the code loaded, and only code in COMMON-LISP is likely to be there for the having if the file itself isn't loaded.
If your patch (I haven't actually tried it, so...) affects arglist lookup it would be a misfeature for me: whenever Slime fails to give me the arglist I expect I know something is wrong.
How about for a more conservative version: if the symbol isn't found in the current package, prompt user for an alternative package, defaulting to CL-USER?
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." .
I would occasionally benefit from patch in cases when browsing a file whose code is in a package as-of-yet-unloaded, and meta-pointing to a symbol in COMMON-LISP, but that's about all:
I work with the code loaded too but I often work with lots of packages and so am often not in the package that some symbol I want to see is defined. For example, I'm working on function foo and I know that function bar is related to its implementation but bar isn't exported. Right now, I can't type bar and meta-point. I must either navigate to the file in which bar resides myself or type package::bar and meta-point. All the patch does is save me from having to type / remember the package before meta-pointing.
If your patch (I haven't actually tried it, so...) affects arglist lookup it would be a misfeature for me: whenever Slime fails to give me the arglist I expect I know something is wrong.
The patch doesn't alter arglist. It only alters meta-point. A better patch (better in my opinion <smile>) would also alter the behavior of symbol-completion so that I could type "bar meta-tab" and have Lisp find package::bar for me.
How about for a more conservative version: if the symbol isn't found in the current package, prompt user for an alternative package, defaulting to CL-USER?
For my use case, this would be no better than the current behavior of slime... milage may vary, etc.
thanks for the comments,
-
Gary King -
Helmut Eller -
Marco Baringer -
Mikel Bancroft -
Nikodemus Siivola