This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-07
Channels
- # bangalore-clj (3)
- # beginners (103)
- # boot (13)
- # cider (16)
- # cljs-dev (192)
- # cljsrn (44)
- # clojure (147)
- # clojure-dev (1)
- # clojure-italy (79)
- # clojure-norway (1)
- # clojure-russia (9)
- # clojure-spec (4)
- # clojure-uk (34)
- # clojurescript (65)
- # core-async (1)
- # core-logic (2)
- # core-typed (5)
- # cursive (1)
- # datascript (9)
- # datomic (26)
- # emacs (8)
- # garden (1)
- # hoplon (11)
- # humor (1)
- # jobs (1)
- # jobs-discuss (8)
- # jobs-rus (3)
- # leiningen (1)
- # luminus (1)
- # lumo (1)
- # mount (6)
- # off-topic (16)
- # om (10)
- # om-next (1)
- # onyx (10)
- # parinfer (10)
- # pedestal (25)
- # re-frame (27)
- # reagent (3)
- # rum (47)
- # uncomplicate (1)
- # unrepl (34)
- # untangled (120)
- # vim (58)
had a thought about neovim-client the other day. What if vim plugins took a "blob" of neovim client (concat all the nses together with a unique prefix to the ns) & sent it to the running repl when they started up. And then instructed it to look at the unix socket that neovim automatically starts, or some other way of opening the msgpack connection. That way there's no slow jvm startup (just uses the existing jvm), but you get to do everything in Clojure (yay!). This template could automate the work if we figure it out. Just gotta do the figuring out part 😉. Unrepl can produce a blob.
> concat all the nses together with a unique prefix to the ns Which nses? Once for each plugin using the neovim-client or once for all? > sent it to the running repl when they started up This has the additional problem of having to star nvim at a folder which already has a repl open..
Once for each plugin using neovim-client. But theoretically you could do once for all. I think the former is better (npm-style deps ftw!). Is that true? I figured you could just hot load your plugin in on first command / on connection / on missing namespace failure.
Maybe we can, but then we're just postponing the load to happen for the first time a command is called, but multiplying it for each separate repl that is open. Also, we end up having several different plugins running on the same repl instance/process, which can lead to a bug in one plugin degrading all other plugins sharing the same process.. Additionally, we're biasing clojure plugins to be used only by clojure developers, since we're requiring a repl to be open... I'm not sure we want that...
for a slow startup plugin to spread to an existing host is a pretty powerful tool I think :thinking_face: I agree we shouldn't require it to be that way. It's a nice thing to support though.
I mentioned vimpire because I was making vampire references, not because I'm excited about it necessarily (just ftr)
You’re welcome to include it, I’d very much like to have a clojurescript solution where there is no need to npm external dependencies though
it feels very tricky to have a ‘nice’ solution where I’d like a nvim plugin to be a. setup like a regular vim plugin e.g :PlugInstall
and b. written in clojure(script)
It’s not the end of the world, it just bugs me that there is so much setup required to get a plugin to work
I think a small golang shim with vimscript or lua driving it is the only/best way to have something lightweight
it’s a general pain, I usually recommend atom/protorepl for new developers as a bulletproof way to setup a clojure environment but even that will fail because tools.namespace is missing if you’re on a machine that has never run clojure before
nice to see that the package.json deps are gathered without an extra step from the user too
I don’t know the first thing about node-host or <external_language>-hosts in general for neovim but it would be nice if we could include the npm install call
like cider middleware, load up the package you need to communicate with neovim for the language host that you’re using
https://github.com/cgrand/unrepl/blob/master/tasks/leiningen/unrepl_make_blob.clj it's not a complex piece of code.
@jebberjeb I'be been thinking about Stu's talk quite a bit, inspiring some re-thinking of how I think about repl integrations