This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (3)
- # beginners (28)
- # calva (5)
- # clj-kondo (17)
- # cljsrn (1)
- # clojure (69)
- # clojure-dev (23)
- # clojure-europe (1)
- # clojure-italy (27)
- # clojure-japan (1)
- # clojure-nl (5)
- # clojure-spec (34)
- # clojure-uk (87)
- # cursive (93)
- # datomic (15)
- # duct (6)
- # emacs (6)
- # events (2)
- # garden (1)
- # graalvm (4)
- # jobs (3)
- # malli (1)
- # off-topic (14)
- # onyx (1)
- # pathom (8)
- # pedestal (2)
- # re-frame (13)
- # reitit (5)
- # shadow-cljs (13)
- # sql (13)
- # test-check (5)
- # testing (3)
- # yada (1)
I use a formatting tool and occasionally a string-pluging in intellij. lemme check
The plugin is called
string manipulation and allows you to sort a subselection. This works for me because i can order arbitrary selections such as
We use https://github.com/gfredericks/how-to-ns with
:sort-clauses? true as the linter btw
Just had cursive break down on me. Nothing gets resolved anymore, but is highlighted as an error. I've removed and re-added the project through the Leiningen integration, invalidated caches and restarted, and even recreated the whole Idea project. Any ideas?
I have a single IntelliJ project with multiple modules. Module A depends on library B via a
:local/root dependency. Cursive automatically creates/imports library B as some sort of IntelliJ Module. Normally this behavior is nice but it seems to be preventing a critical task. I want to open a REPL in library B with some extra aliases. Normally you can do this by opening the Clojure Deps panel, expanding the project you're interested in, and checking the alias boxes you need. Because Cursive automatically imported library B, it does not appear as a top level item in the Clojure Deps panel and therefore does not have the aliases checkbox. I can create a REPL through the usual mechanisms, selecting the Cursive-imported module B but, again, no way to select the aliases I need. I tried adding library B by doing File > New module from existing sources and selecting library B's deps.edn. This presents the "Import Module from Deps" popup. When I select "OK", I get a message that says "The project is already registered." Is there no way to create a REPL in library B with selected aliases? This is a big workflow impediment.
There’s only one Aliases tree in the toolwindow, and those aliases apply to all projects. That’s because there’s no way to pass aliases transitively to sub-projects in deps. However that aliases tree isn’t used at all for run configs like REPLs, it’s only used when syncing the project to IntelliJ.
To add an alias when running a REPL, in your REPL run config choose “Run with Deps”, choose module B, and you should be able to just enter the aliases in the alias box there.
I see multiple Aliases folders - one under each sub project. The bigger issue was that every time I changed the deps in library B, Cursive won't refresh its deps.
This is actually quite a big annoyance. We have several cases like this and none of them will refresh their deps without refreshing a parent lib first.
In library B, all the deps in the
:test alias are never refreshed and therefore all marked as "cannot be resolved"
This has another consequence - all symbols that have been marked as Resolve as... change their indentation back to the default. This causes code to get reformatted with no way to fix it.
Sure, I understand it’s slightly counterintuitive, but does it actually cause a problem if you refresh A in order to refresh B?
ok, I’ll look at that - thanks for the report. Unfortunately the Deps support is based on an inflexible IntelliJ API. I want to migrate it off due to all the recent breakage and problems like this, but it’s a big job.
Right. It's quite an issue for our setup. It's possible that removing all project-A type projects, then adding all project-B type projects, then adding project-A type back in again would work.
You will always get "Cannot load metrics_stream_test.clj file into the active REPL. It is not in scope for the module used to start the REPL."
Deps doesn’t make this any easier unfortunately, since aliases are not transitive there either.
Oh, I see - changes in B’s project are not auto-imported. If changes in B’s deps.edn triggered an auto-import of A, would that be ok?
We can do what you mentioned earlier by specifying the aliases explicitly in the "Run with Deps" text box. That approach will let you load things in the REPL but not resolve symbols from the aliases specified. This is annoying and leads to bad formatting of code using the unresolved symbols.
Haha ok. Not sure if IntelliJ APIs are a blocker here but being able to move a Module's "sub-module" to a top level Module would fix this too.
Hmm, ok. Another possible workaround would be to disable the local/root auto module import thing for certain projects and let the user explicitly add them as a module.
Does this capture it all? https://github.com/cursive-ide/cursive/issues/2214
4. This actually works with the caveat that your deps in the
:test alias may not actually be on the classpath.
Not sure how the suggested solution would really solve the problem though. You'd need to know which aliases in project B to update.
Yes, you’d have to do that selecting the Aliases in the A project, which means you need to know how B was pulled into the project.
It’s actually worse than that, if you also have another top-level project C which also pulls in B, then the aliases will be different there.
The way that lein works is that there’s one single top-level Profiles tree, which applies globally to all projects.
Maybe that is the simplest solution here. It’s what I thought I had implemented, but I didn’t realise that the aliases are currently per-project.
Hmm. So that makes sense for the resolving of symbols in the editor. It isn't great for starting a REPL. The Run with Deps should let you select the aliases per project though.
If you take a step back, really aliases should be per-project. That's the mindset you have when working with deps.edn so that's the mindset people would have when working with Cursive. Whether that actually fits into IntelliJ's model is another story, it sounds like.
per-deps.edn. IntelliJ projects are just a way of viewing many individual deps.edn projects.
Right. However literally no-one has ever complained about the profiles support in lein, and it’s how the Maven support in IntelliJ works too.
I think you’d have to get pretty crazy with inconsistent meanings for the same aliases for a global list (for project sync purposes) to become a problem.
Thinking about it, it would only be a problem if you have an alias that pulls in a dep or adds a source root for one project, which also pulls in things in a different project that you don’t want. For project sync purposes you mostly want a superset of everything anyway, so it seems unlikely to cause a problem.
Sure, that's fair. The reason it feels weird to me is it is conflating IntelliJ's definition of projects with deps.edn's definition of projects.
Right, but the same is true of lein and Maven, and it’s not been a point of confusion there (at least, definitely not for lein)
I'm curious if there's other reasons for that. deps.edn has certainly changed my mental model for this stuff.
Anyway, having a superset for resolving symbols would work. I can't think of a reason why you wouldn't want that. You would then (always?) want to select the individual project-level aliases to start your REPL with.
Maybe some checkboxes in the run configuration box so I can remember what aliases are available in that project? :)
So, I’ll fix the global alias bit. That was my intention anyway, and I didn’t realise it wasn’t working like that. If there do turn out to be problems with that, I can perhaps allow customisation of the global list at a project level if required.
Ok, this sucks. I cannot make that change, nor can I change this in any non-confusing way.
I’m going to migrate the deps support off that API. It will probably take ~2 weeks, but it’s going to be my main focus until I get it done.
Then I’ll be able to do whatever changes I need to, and you’ll have new and exciting bugs to find 🙂
not sure if an issue or I'm using it wrong but sometimes parentheses are being too insistent.
Try to delete one of the parentheses or try to make it
(foo). Can't quickly unwrap it.
Not sure. Was looking for plugin settings but no luck. Do I miss anything? "Paredit" toggle appears only in my quick actions but it doesn't affect my issue.
And, in case I want to keep it on, then
Raise does the unwrapping. Thanks, rubber duck in its glory))
Two cents, it's common to have Unwrap action in IntelliJ, usually, bind to Ctrl + Shift + Delete. Could be a secondary key mapping for
Raise. Awesome plugin, overall!