Helmut Eller eller.helmut@gmail.com writes:
On Sun, Sep 07 2014, João Távora wrote:
[...]
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,
With "part of symbols names" I mean those symbols in ELisp that use "slime" or "sldb" as prefix when one would use packages in Common Lisp to make them unique. Apparently you have already renamed most (all?) of those.
I'm still missing the "sldb-" symbols but I have already tried and this presents no big problem. But again, not super-clean either, because there are symbols in the CL namespace that contain "SLDB", and some are user-customizable. I either leave those be or have to implement abstractions.
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?
People who are debugging some wire format issues probably wouldn't load Swank and slynk (or whatever name you choose) at the same time. At least I wouldn't load any unnecessary components when debugging.
I don't know about that: when an unexpected error happens, the first thing I do is not teardown my environment and start without unnecessary compoenents, because I don't know who those are in the first place.
My view is that people who for some (slightly questionable) reason, do want to have both Swank and the proposed Slynk in the Lisp, can very well add an extra line to their configuration and see
(:emacs-rex (slynk:connection-info) nil t 1)
in the events buffer.
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.
That problem is the same for SWANKR or similar servers. The right place to fix such issues is the extension.
Not really, and the problem is not only sexp nesting. sly.el calls interfaces where a second "slimefun" is mentioned like in slime-repl.el's own
(slime-eval-async `(swank:listener-save-value ',slimefun ,@args) ...)
Which is something that I added precisely for compatibility with SWANKR (See the discussion with Christopher Rhodes in https://github.com/slime/slime/issues/140).
Perhaps you consider it abuse -- I don't, hence the quotes earlier -- but it's also very convenient. It allow the proposed Slynk to serve inspection requests for both SLIME and SLY clients. For example, SLY implements multiple inspectors streams with a call like
(sly-eval-async `(swank:eval-for-inspector ,inspector-name ',slimefun ,args))
, which applies SLIMEFUN to ARGS in INSPECTOR-NAME's context. But the SLIME client, who doesn't support multiple inspectors, will still see its SLIMEFUN request honoured as always. And so Slynk remains backward compatible to SLIME clients.
But anyway, changing `sly-net-send' to walk the sexp just before sending doens't seem hard to do, and though I haven't measured, doesn't sound computationally expensive in the RPC context.
João