This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-02
Channels
- # announcements (1)
- # architecture (1)
- # aws (21)
- # babashka (37)
- # beginners (173)
- # boot (12)
- # chlorine-clover (5)
- # cider (36)
- # clara (11)
- # clj-kondo (25)
- # clojure (128)
- # clojure-europe (7)
- # clojure-finland (3)
- # clojure-germany (2)
- # clojure-nl (57)
- # clojure-uk (23)
- # clojurescript (71)
- # clojurex (1)
- # core-async (30)
- # core-typed (5)
- # cursive (35)
- # datomic (8)
- # duct (4)
- # emacs (8)
- # exercism (41)
- # fulcro (116)
- # jackdaw (4)
- # jobs-discuss (6)
- # juxt (4)
- # kaocha (16)
- # leiningen (14)
- # malli (5)
- # observability (4)
- # off-topic (2)
- # pathom (19)
- # pedestal (29)
- # re-frame (64)
- # reitit (18)
- # ring (8)
- # shadow-cljs (3)
- # sql (13)
- # tools-deps (32)
- # tree-sitter (5)
- # yada (17)
> It should be a sequence of strings. All sequences are represented as lists in bencode. @bozhidar Ok! I've implemented the "classpath" op and this seems to get rid of the infinite request loop issue 🎉
I think it still makes sense nontheless to add a special signal to the describe op. This way you can know this is a CLR repl, just in case you decide to do anything special with it in the future. For now I'd say things work really well making CIDER believe we're a JVM, But I'm concerned future updates trying to make the experience better for JVM users means things transparently break for Arcadia/CLR users. If you could check some flag before sending JVM-specific code, that'd be really great! 😅 I'm sure it will also help for other even more obscure dialects of clojure wanting to have editor support. As a side-comment, since you're taking this route of providing fallback functionality when middlewares are missing. When it makes sense to do so, I'd encourage you to try make things as platform-independant as possible (that is, stick to cljc). In the long term that would mean better support not only the small-ish CLR community but the CLJS ecosystem as well!
> For now I’d say things work really well making CIDER believe we’re a JVM, But I’m concerned future updates trying to make the experience better for JVM users means things transparently break for Arcadia/CLR users. If you could check some flag before sending JVM-specific code, that’d be really great!
Well, it’s good I’m the maintainer for both CIDER and nREPL, so I’ll definitely be mindful of making such changes. Actually when I find myself with a bit of time I plan to make more changes in the opposite direction. 🙂
> I think it still makes sense nontheless to add a special signal to the describe op. This way you can know this is a CLR repl, just in case you decide to do anything special with it in the future.
Yeah, definitely. I’ll just need to decide where exactly to put it and how to make it.
versions (dict
clojure (dict
incremental 0
major 1
minor 10
version-string "1.10.0")
java (dict
incremental "1"
major "10"
minor "0"
version-string "10.0.1")
nrepl (dict
incremental 0
major 0
minor 7
version-string "0.7.0-beta1"))
That’s part of the describe
response. It’d be nice if your server returned some CLR version info and we can also added a extra key to the nrepl
map - e.g. something like name/implementation/flavour
.
> As a side-comment, since you’re taking this route of providing fallback functionality when middlewares are missing. When it makes sense to do so, I’d encourage you to try make things as platform-independant as possible (that is, stick to cljc). In the long term that would mean better support not only the small-ish CLR community but the CLJS ecosystem as well! That’s the dream, but we’ll need some time to get there.
that means, when I open project.clj, I have to go to the http://main.cl ns file and open it. cider is basically not that aware of the project level stuff ?
See also https://docs.cider.mx/cider/usage/interactive_programming.html and https://docs.cider.mx/cider/usage/cider_mode.html
Ever considered using the clj-kondo analyses data: https://github.com/borkdude/clj-kondo/tree/master/analysis to add support for auto-completion of var names, macros, fns, namespaces, to show arities and to show doc, as well as for jump to definition, show uses, and add name refactoring?
I guess CIDER doesn't want to include clj-kondo in its dependencies, but maybe it can be set up like refactor-nrepl, like some sort of add-on
It’s fine to use it via the middleware, btw. I think we already discussed this in the past. That would have the advantage that users won’t have to install anything and I guess if we don’t have to shell out life on Windows would be easier. 🙂
Hum... I think that be a bit beyond what I'm thinking. Since middleware means running REPL no? And I'm thinking of the possibility of adding a REPLless auto-complete. Though I guess middleware clj-kondo would be nice for linting, where users don't need to install it.
or maybe it doesn't fit with the philosophy of CIDER which is based on nREPL, which implies a REPL?
Yeah, that’s true. CIDER is first and foremost REPL-powered tool (like SLIME and most similar Lisp programming environments).
I’d be open to something like this (depending on the complexity of the integration). In general I’m wary of adding tool-specific functionality to clojure-mode
or increasing a lot the level of complexity there. Alternatively this can be a separate minor “kondo-mode” or something like this. I haven’t played enough with kondo to have a good opinion about the best course of action.
How does Emacs handle auto-complete for other languages? Is an emacs-lisp parser implemented for them?
There were refactorings that moved to be handled by clojure-mode or cider itself over time I believe