This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (10)
- # beginners (62)
- # boot (12)
- # cider (97)
- # cljs-dev (171)
- # clojars (1)
- # clojure (224)
- # clojure-italy (4)
- # clojure-nl (2)
- # clojure-russia (1)
- # clojure-spec (41)
- # clojure-uk (68)
- # clojured (7)
- # clojurescript (115)
- # community-development (4)
- # cursive (2)
- # data-science (1)
- # datomic (18)
- # duct (40)
- # emacs (1)
- # events (1)
- # fulcro (148)
- # funcool (2)
- # graphql (2)
- # immutant (3)
- # jobs (3)
- # keechma (1)
- # luminus (2)
- # numerical-computing (1)
- # off-topic (19)
- # om (6)
- # parinfer (10)
- # pedestal (15)
- # precept (86)
- # reagent (12)
- # ring (3)
- # ring-swagger (2)
- # shadow-cljs (42)
- # spacemacs (19)
- # specter (17)
- # sql (11)
- # tools-deps (78)
- # unrepl (62)
- # vim (28)
What is a good way to retrofit actions? I'm thinking about extensions to the client by third party libs. Thus far you'd have to regen the blob. Should there be some way to register actions after the fact? Once done so, they could be cached for a shaded blob.
This is exactly the situation I had in mind. Getting the support code on the server is easy due to the sideloader. There we can hook into the search path on the client side. Proper shading is up to the library. However, the library defined actions should behave like the official ones, cf. ensure-ns. Adding locally defined actions to the client is not a problem.
Hrmmmm.... Typing that makes me wonder, whether we can do this without unrepl even bothering. A simple: make-me-an-action-of-this-form would be enough. No need to actually modify the blob at all.
That would also take away the need to actually generate a blob beyond the unrepl one. Yeah! Got rid of a compile step for the client. Shading and b64ing are still necessary, though.
at first I thought it was a must have then I came to believe that the blob was king (at the same time my understanding on what unrepl changed from “an end product” to “a tool to create not-too-sucky private protocols”)
the pendulum is swinging back (don’t worry there’s a damper somewher, each oscillation is less wide than the previous one)
I’m trying to find what pieces of unrepl to expose at runtime. I’m pretty convinced that
write is amongst them (there’s already something in
So the way to declare/patch/hook-up-into actions is certainly going to happen through
write: write a message and let the client use it.
:thinking_face: actually it doesn’t work because it’s the server we want to modify, adding actions at some points of the lifecycle and these actions would need some context to be passed in (eval if, session id etc.). A lot of things to commit to (from a design point of view) for which I don’t have a right answer yet.
Plus dynamic registration only makes sense for actions known to the client (which is a finite set)
I'm confused. Actions are just functions to be called. Blessed with hypermedia fairy dust. I mostly use what they return from eval. So they could be handled completely on the client side, no?
I got vimpire. @dominicm got the fancify-this-code lib. He wants hook into vimpire. And I don't want to depend on his lib. So everyone has to generate a custom blob. Meh :-(
he his lib can hook up into vimpire without vimpire having provisions for it, which kind of features are we talking about?
Eg. Have form. Send it to backend. Get it rewritten. Get it back. That sort of thing. Get info for completion. Get info for dynamic highlighting. Get docs. That sort thing. That's what my actions, FWIW.
I don't want to depend on external libs, eg. for refactoring. But I can provide the infrastructure.
vimpire#RegisterAction("my-action", ...) vimpire#Action(conn, "my-action", bindings, callbacks) That's how the internal ones work.
Unlike nrepl there's less of a need for custom actions. So eval & classloader callbacks should be plenty.
All these actions seem very non-contextual (not related to a specific connection or to a specific evaluation) so eval-over-tooling like @dominicm suggests goes a long way. Also you could consider
(write [:vimpire/client-eval “vimscript”])
So I can basically skip generation of the blob and just fire of required requires on initial connection. The actions are added locally without unrepl ever knowing about them. Having them helps with shading. I'm not sure what real action is then. I can only think of meta things like auxing, interruption, etc.
"Client-side actions" help keeping the infrastructure in the plugin simpler since all the interaction like read tracking and callbacking and whatnot is already handled.
I see. I wonder if bi-directionality is useful. :thinking_face: I can think of some ideas.
I don't get where vimscript fits into the picture here. I rather not have my editor run foreign commands.
@dominicm Things come together. With now hopefully more standard names (<Plug>(vimpire_eval)) and cleaned up documentation. And also a set of small demos. Keen observers might spot that I obviously broke the completion. coughcough
I'm not sure I even want to know how..... Do you think this can be easily hidden away? Or does it require a major rewrite? I mostly use callbacks everywhere...
But it seems to mock around with newlines on the receiving end as far as I understood.