2011/3/30 Helmut Eller:

• Paulo Madeira [2011-03-30 18:27] writes:

...

M-. in slime no longer accepts dspecs other than symbols, since this change: http://bit.ly/dWJiDp I guess that change was made only to accommodate this complaint: http://bit.ly/fZLIxl

This breaks two use-cases for me: to find a specific definition in ACL with M-. (method <name> [qualifiers] (<specializers>+)), and to issue swank:ed-in-emacs in certain IDE hooks/wrappers.

Where do all the qualifiers and specializers come from?  It seems unlikely that somebody is willing type them in or even remember the needed syntax.

I recon it's not likely, but I for instance had to learn the syntax to trace specific methods, so finding specific definitions is about the same.

But even so, before the aforementioned change, it was possible to find definitions with dspec lists. This was useful to me and (probably) a handful of colleagues due to having commands (from the application, the IDE or whatever) calling swank:ed-in-emacs to jump right to a selected definition.

...

I can workaround both cases by extracting the `second' from the list recursively until I only have a symbol, and let Slime list me all definitions with that name, but I believe this is sub-optimal when I already know the definition I want. I believe this can happen in other implementations too.

Perhaps using a recursive non-interning reader, e.g. stop reading if it cannot find-symbol.

I don't want to re-implement a reader.

When I suggested this, I was thinking about creating a recursive function that would recurse on #( and otherwise would call swank::parse-symbol until #). Giving it a little more thought, I understand you. The problem is that method specializations (as recorded in ACL, but others probably differ little) may include (eql <form>), where form is typically a symbol, but it may as well be a number, a character or a compound form containing them, etc.

I don't know then... To avoid interning, this feature was muffled. Maybe it could be customizable, i.e. have yet-another Swank configuration variable, which default I wouldn't mind to be the non-interning option. The backend support is still there, it's just that the reader in swank:find-definitions-for-emacs is now swank::parse-symbol instead of swank::from-string.

I think there's yet another option. In Slime, slime-ed could call a Swank find-definitions function that interns, because it seems to me it's only called remotely by swank:ed-in-emacs, which already gets the dspec. Or even, have swank:ed-in-emacs find definitions and hand them to Slime (this option would probably be more appropriately named find-definitions-in-emacs).

Paulo Madeira

2011/04/02 Helmut Eller:

A compromise would be to allow interning if the user explicitly enters the name with C-u M-. but avoid interning when M-. is invoked without prefix argument.

I don't mind that at all.

Meanwhile, I've seen that contrib/swank-arglists.lisp already has a non-interning reader that only parses symbols. It could be extended to understand standard CL numbers and characters, perhaps only supporting plain base-10 integer and implement others (e.g. ratios, reals, #c #o #r #x) until someone actually uses them.

Yes, swank:ed-in-emacs should call find-definitions directly

Right.

BTW, I dare ask :) I'm not really interested in this, it's just an idea: would it be (easily) possible that it also accepts an actual (generic) function, method or class? For instance, in the running lisp's repl, you could somehow obtain such an object as the result of an expression and then just (swank:ed-in-emacs *).

Paulo Madeira