[Slime-devel] SLY, a fork of SLY

[João Távora]

Helmut Eller <eller.helmut at gmail.com> writes:

> On Sun, Sep 07 2014, João Távora wrote:
>
> [..,]
>> My reticence to this particular renaming stems from the fact that the
>> RPC protocol between Emacs and the Lisp process is itself based on the
>> identifier "swank" *and* on its package-designating quality. This is an
>> example of what goes on the > wire
>>
>>    (:emacs-rex (swank:connection-info) nil t 1)
>>
>> If I blindly rename "swank-">"slynk" in all symbols, packages and parts
>> of symbols, as is being requested, SLY will be immediately locked out of
>> the existing communication protocol.
>
> In swank-rpc.lisp is a function SIMPLE-READ that can be used to parse
> the string that comes from the wire.  You could replace the call to
> INTERN there with something that splits the string at the #\: and then
> map "SWANK" or other package qualifiers to your own packages.

It is an interesting hack indeed. Thanks.

> Doesn't sound so hard and it would not need any conflicting package
> nicknames.

Well, I would still need to rename the rex requests themselves as in

   (sly-eval `(swank:list-all-package-names t)))

So as to comply with your "part of symbols names" demand and, more
importantly, to keep `sly-edit-definition' capabilities.

This last bit is, incidently, one of the drawbacks of your previous
solution compared to nicknaming packages, since for anyone looking at
the wire (e.g. *events* buffer) strings would SIMPLE-READ to completely
disparate symbols. Now, imagine there is indeed a SWANK server running
int the Lisp image and the confusion this could cause. Would this be
easier to debug than an early abortive "Can't create package because
there is a conflict" error?

After having done that, I would need the reverse indirection in
`sly-net-send`, and would have to walk the sexp there, since some
extensions "abuse" it and send nested sexps.

As I said, not hard, but also not trivial to consider the consequences.

João