Helmut Eller eller.helmut@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