Luke Gorrie luke@bluetail.com writes:

Peter Seibel peter@javamonkey.com writes:

...

I don't know if I saw it here, on c.l.l., or in my dreams but I seem to recall someone saying they were working on adding a generic function/method browser to SLIME. I.e. something by which you could see all the methods defined on a gf and then remove particular ones easily, etc. If so, how's it coming along?

Thomas Schilling mentioned this in CLL.

This project is not dead, but Thomas has not very much time at the moment. So any results will probably take a while.

[Thomas: Prove me wrong! *g* But remember, no 1.0 in Logik, no beer. :P ]

Regards,

Thomas Schilling tjs_ng@yahoo.de writes:

The front-end looks simple. I'm heavily copying from the xref stuff.

I don't like the sound of "copying from" :-). I think the easiest way would be to make "remove method" an add-on command that can be used in the existing XREF buffer on any entries that happen to represent methods.

If you hacked the XREF'ing Lisp code to return some extra info saying "this is a method and here are its specializers" then that could be used to implement REMOVE-METHOD.

-Luke

Ok, so everyone using acl62 or sbcl can test it now. Using C-r on a method in the xref-buffer that pops up when you press M-. on a gf name you can now remove the selected method.

On acl62 this doesn't work for methods with eql-specializers.

Should work even with custom method qualifiers.

We need some more backand support. But should be simple.

I want to remove the line of the method if it was removed, but didn't find a standard function for deleting a line.

Any probs with the key bindings?

regards

-ts

Luke Gorrie wrote:

I've got a couple of requests. How about putting the method signature into the `hints' property list of the location structure?

Ah, I think that would be better indeed. I didn't notice that feature.

Also I think it'd be a nice extra touch to remove the method's line from the xref buffer when it's removed.

Yes. I already put a FIXME there ;)

...

Any probs with the key bindings?

`C-r' is awkward because it clobbers `isearch-backward'. I'd suggest just `r' since the buffer is read-only.

I rely on overwrapping ;) Well, my problem is that it's too likely to press `r' by accident. Though, C-c r or C-c C-r would be too much complication, wouldn't it?

-ts

After some little misunderstandings I finally reworked my patch.

I tried to use the hints field of the location structure but it turned out (too late, already rewrote quite much) that this won't work if a location is not available.

(In that case an error struct is returned and I didn't feel it was a good idea to put a hint field in there. I think it's better structured this way since a method-spec is not really an extra info for a location. I'd rather suggest adding a general item-info structure if there's more information going to be added. --Nevertheless, in case you prefer adding the hint-property to the error struct I still could send the diff for this other approach.)

So I only changed the keybinding to C-k (according to a suggestion by Sean O'Rourke) and make it remove the corresponding line.

Andreas' suggestion of a dired-like behaviour is also nice but I think the current way it works is sufficient.

Still we need some testing for SBCL (haven't used my linux for quite a while) and backend support for all implementations other than Allegro 6.2 for win32.

regards

-ts

Andreas Fuchs wrote:

I tested this with SBCL briefly, and it seems to work (can remove methods I defined on print-object). I had to fix the paren balance on that defun, though:

[...]

...

• (move-to-column col))

                       ^
	    )

Oh, had no problems with my local copy. Probably I did the diff before I fixed this. Though, shouldn't be much more bugs ;)

Unfortunately it looks like this won't be the final version, neither. See Helmut's mail.

Thanks! This is really neat.

Hah! If you knew what I'm still planning to do ... ;)

-ts

just for the archives :) my original cc didn't work, but the p.s. is obsolete now

-ts ,-----

Thomas Schilling tjs_ng@yahoo.de writes:

...

• "Takes a method description and tries to remove this method.

+MSPEC string must be a string representation of a list with the format +(METHOD NAME {QUALIFIER}* SPECIALIZER-LIST).

[...]

...

•              (fboundp (second sexp)))
  

•         (let* ((gf (fdefinition (second sexp)))
  

•                (qualifiers (loop for q in (cddr sexp)
  

•                                  while (not (listp q))
  

•                                  collect q))
  

•                (specializers (car (last sexp)))
  

•                (method (find-method
  

•                         gf qualifiers
  

•                         (mapcar (lambda (x)
  

•                                   ;;FIXME: is it really a good 
  

idea

•                                   ;;to call eval here?
  

•                                   (if (consp x)
  

•                                       (list 'eql (eval (cdr x)))
  

•                                       (find-class x)))
  

•                                 specializers)
  

Passing the "method descriptions" as a strings between Emacs and Lisp is a bit problematic (read-case, package ...). If I where to build a GF browser I'd keep the list of methods as first class values on the Lisp side. The index in the list could then be used to refer to a particular method.

Well, that would make many things easier/more portable. And it would make it work with eql-specializers on acl62.

Ok, I'll give it a try.

What do you think of the current style of making it a xref add-on? Would you prefer a stand-alone gf browser buffer? (or do you have no opinion on this issue?)

-Thomas

p.s.: cc'ing to slime-devel@common-lisp.net doesn't seem to work. at least I couldn't see any newer messages in the archive and the never appear on gmane.lisp.slime.devel