[slime-devel] swank:find-definitions-for-emacs doesn't support definition names other than symbols

[Paulo Madeira]

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