[slime-devel] eval-in-emacs and 'window'-debugger

[Helmut Eller]

Antonio Menezes Leitao <aml at gia.ist.utl.pt> writes:

> Is there a different swank function for that? (in the
> emacs-lisp-interface from Franz I used a lep::eval-in-emacs that did
> precisely what I needed).

No, there's currently no such thing.  We could probably generalize the
code that reads input from the REPL (see READ-USER-INPUT-FROM-EMACS)
to support arbitrary calls.  But this will not happen before the Great
Release.

> This is very useful to provide refactoring operations (that operate on
> the Lisp side) that need to interact with the user using emacs lisp
> operations such as y-or-n-p or read-from-minibuffer.

I think it is good principle to keep the interaction between Emacs and
Lisp to a minimum.  I'm not sure, tough, whether such Y-OR-N-P-style
functions help to reduce the interactions; experience will tell.

> I know that it might be difficult to find a general scheme to
> translate from emacs lisp values to common lisp values but all I need
> is symbols, strings, numbers and such.

Yes, keywords, strings, numbers, and cons trees map quite nicely
between the to dialects.  For other objects it's better to exchange
some index or numeric id.

> A few years ago I developed a 'window'-debugger and 'window'-inspector
> for Ilisp+CMUCL similar to what I used in the Explorer Lisp Machines.
> I recently adapted it to Slime+Whatever-Common-Lisp-slime-supports.
> If anyone is interested I can post it.

Please post the code, so that we have some examples for your needs.

> 1. The function swank::inspected-parts should provide a recognizable
>    value for unbound slots.  Here is one example in SBCL
[...]
> 2. The function swank::frame-locals doesn't distinguish valid locals
>    from invalid ones.
[...]

We have this UNBOUND-SLOT-FILLER objects, but I think they aren't used
very consistently, probably only for Allegro.  I'll have look at it.

Helmut.