This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-18
Channels
- # beginners (56)
- # boot (1)
- # cider (96)
- # cljs-dev (148)
- # clojure (60)
- # clojure-austin (11)
- # clojure-france (2)
- # clojure-italy (5)
- # clojure-russia (11)
- # clojure-spec (31)
- # clojure-uk (5)
- # clojurescript (52)
- # community-development (37)
- # cursive (3)
- # data-science (8)
- # datomic (14)
- # devcards (2)
- # emacs (1)
- # fulcro (13)
- # hoplon (1)
- # immutant (2)
- # luminus (3)
- # off-topic (2)
- # onyx (16)
- # parinfer (38)
- # re-frame (8)
- # reagent (5)
- # shadow-cljs (332)
- # spacemacs (5)
- # specter (5)
- # sql (6)
- # vim (52)
@dpsutton yeah well you might say that they essential do the same thing, except that cider exposes functionality by hijacking the main medium of communication and wrapping in bencode while inf-clojure does not. With orchard
out now in theory inf-clojure
could call those functions directly.
i was thinking of the cider-nrepl middleware. inside of the that we can do quite a bit of reasoning that isn't exposed by a repl
i like inf-clojure specifically for not putting anything additional into the project. no dependencies, just clever interaction with the repl
At some point you need deps for more complicated features, one solution is to load them server side..
unrepl
loads them from the client instead, which is very interesting...sending a packaged up payload that gets evaluated repl side and adds functionalities
@dpsutton Old versions of CIDER didn’t use any middleware and were just evaluating some complex snippets of code to get stuff down, but although as a client this seems simple, it’s both extremely brittle and extremely hard to maintain after a certain point.
Any complex editor support requires a ton of logic and you need to put it somewhere. Whether you’re upgrading an existing REPL and you setup a special REPL doesn’t matter that much in the end of the day - in both cases you needed someone to augment what the REPL can do so, so it’s actually useful to the editor/whatever.
In general if people are happy with the feature set of the inf-clojure
they should probably stick with it, as it was created with simplicity in mind. If you end up needing more features (e.g. tracing, debugging, whatever) you’ll need CIDER.
I do hope that CIDER will get to a point where we’ll support REPLs like lumo and planck, but that’s not going to happen any time soon as first we need to implement some support for socket repl and then reconcile the differences between hosted and self-hosted cljs repls.
Never. 🙂 I’ve always viewed them as complementary projects, otherwise I wouldn’t have created both of them. I guess it’s time for me and @richiardiandrea to finally created some comparison table for them and extend the readme to answer some of the FAQ regarding the differences between them.
Is it possible to have inf-clojure use two connections so that *1 doesn't get lost in a repl?
@ghadi can you give me an example of what you would like to have, I don't quite get it 😄
If user-submitted forms and inf-clojure submitted forms were on different sockets, there would be no problem
Thanks @bozhidar for the answer. 🙂
@ghadi I see now, so inf-clojure
shouldn't probably care about this problem, as you know unrepl keeps a session. If I had to add support in inf-clojure
I would basically a inf-clojure-cmd-preamble
that executes some session saving code each and every command. Other ideas and an issue open are more then welcome ;)
Also, the completion command is completely configurable so you can wrap it in custom code, I think there is an example in the code base
can you do session saving code like that? can you tell a repl not to let this expression clobber *1
?
For lumo we do some wrapping already: https://github.com/clojure-emacs/inf-clojure/blob/master/inf-clojure.el#L899
CIDER gets around this by running two sessions to each repl. there's a tooling session alongside the user session
Yes that is the classic approach inf-clojure
does not have
There is a lot more to discover in here: https://dev.clojure.org/display/design/Socket+Server+REPL
So @ghadi if you use the socket repl, probably a wrapper could get stored session data
If I understand correctly the socket repl stores the *1
, but I am not 💯% sure
I would need to try that out on mobile now
I think separating into a command stream and a user stream is useful - the preamble idea is a hack (sorry)
It is a hack :)
Ghadi, happy to help with the code base, keep in mind that that same code could already be in cider
or spiral
in some way or another
It is in some way or another but honestly both of those projects are approaches that are not as simple as inf-clojure could be
Inf-clolure was born as simple wrapper over comint
which unfortunately is a limitation
I know I know, just putting all the cards on the table
Yes you can iirc
For the "tooling" connection there is a comint
redirection
To a hidden buffer
But yes iirc multiple REPL buffers use a new comint
connection/process call
The redirection is obviously a hack as well 😃
I never had this need because probably lumo
saves those for me btw...which is interesting as well
@ghadi I also wanted to past this excerpt here: Socket sessions To allow a tool to share repl context with a user's repl, we want to have two repl client connections that share a "session", essentially the dynamic context in which they evaluate things. This allows an internal tool repl to get access to dynamic variables like \ns or potentially any other dynamic variable binding state. To record binding state: After every eval in the socket repl, get and store the current bindings in the server map To use binding state: Allow a socket client repl to attach to a different session - this is done by recording the attached session id in this session's state Before every eval, if client is attached Get attached session's bindings Replace the stream bindings (in/out/err) with the client repl's bindings (don't want to hijack those) Push the attached session's bindings After every eval, if client is attached Pop the bindings
you can build something nearly as sophisticated as unrepl or cider with a simpler approach
I am neutral on that, as long as we keep productivity high and we keep things simple I am open to anything...I switched to inf-clojure
because of the ease in debugging potential problems with "middleware" (which in inf-clojure
are just repl functions)
I think that's what spiral
is doing no?
I look at the experience from the perspective of the core LangServer API -- (code completion, hover, jump to definition, find references). While it would certainly be easy to want to share *ns*
across user + machine sockets, it is not necessary to properly support those features/APIs
first time I am looking at this: https://github.com/Unrepl/spiral/blob/master/spiral-socket.el
it is good, I am not an elisp expert, didn't event know that Emacs could use a socket like that
comint
gives you history search and low-level response facilities though, so I don't know if it can be dropped
what would be very useful is something like clojure.core.server/remote-prepl
but in elisp
I dreamed about that for long time
edn.el
can transform back and forth and I started doing something in inf-clojure
towards that
you could save your repl sessions on the emacs side, including out/err/ret stream separation
yeah that would be doable as well
more work 😅
ah ah 😄!
that's why at some point I wanted to have a socket server implementation of the Server Language Protocol
Emacs already understands that
what is sufficient to do context-specific code completion? active file, cursor position/token
yeah that is definitely good to read, was thinking of doing the same 😄
it's weird because completion (from within a buffer) has nothing to do with any repl's current ns
yep, that's how compliment
does it
i generally don't use autocompletion, but I'm sure it would be nice if it worked consistently for me
Same here, however if emacs had a fully fledged terminal one could use both at the same time, it might actually work (has to be the same socket server session though)