Fork me on GitHub
#cursive
<
2019-08-02
>
guy07:08:21

👋 is there a way in cursive to re-order a :require form to make it alphabetical?

thumbnail09:08:24

I use a formatting tool and occasionally a string-pluging in intellij. lemme check

☝️ 4
thumbnail09:08:22

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 :dependencies in project.clj

guy09:08:21

oh right that sounds neat! I’ll try it out

thumbnail09:08:20

We use https://github.com/gfredericks/how-to-ns with :sort-clauses? true as the linter btw

guy09:08:29

oooh thanks 🙇

Teemu Kaukoranta11:08:58

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?

Teemu Kaukoranta12:08:15

I disabled and enabled Cursive, that seems to have helped

p-himik12:08:30

If you have IDEA 2019.2, there's a pinned post explaining the issue.

Teemu Kaukoranta12:08:07

ah, thanks. I'll keep that in mind if it breaks again

kenny16:08:53

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.

cfleming22:08:19

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.

cfleming22:08:41

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.

kenny16:08:15

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.

kenny15:08:18

Is there a way to refresh the deps for library B?

kenny16:08:31

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.

kenny17:08:28

In library B, all the deps in the :test alias are never refreshed and therefore all marked as "cannot be resolved"

kenny17:08:51

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.

cfleming01:08:07

So you want to be able to refresh the deps for B without refreshing A?

kenny01:08:21

Definitely

cfleming01:08:33

Why is it a problem to refresh A?

kenny01:08:13

Further, refreshing A does not cause the changes in B's :test alias to get updated.

kenny01:08:31

Because I am working in project B independent of A.

cfleming01:08:14

Sure, I understand it’s slightly counterintuitive, but does it actually cause a problem if you refresh A in order to refresh B?

kenny01:08:43

Yes. That does not work when changing deps in B's aliases.

cfleming01:08:56

Yeah, the alias thing is annoying.

cfleming01:08:50

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.

kenny01:08:18

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.

kenny01:08:27

There's no way to even load a test file stored in project B.

kenny01:08:59

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."

cfleming01:08:17

Is that a REPL started with module B as the context module?

cfleming01:08:45

Deps doesn’t make this any easier unfortunately, since aliases are not transitive there either.

kenny01:08:47

Yes but if you changed the paths in the :test alias, it never updates.

cfleming01:08:27

Oh I see, so the problem is also that B’s :extra-paths are never added?

kenny01:08:03

Just tested that. I need to refresh project A to get it to update -- no auto import.

kenny01:08:35

So the project is just with the :extra-deps.

cfleming01:08:48

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?

kenny01:08:56

I suppose that would work.

kenny01:08:09

But it needs to apply for aliases as well.

cfleming01:08:23

Yes, I think that’s a separate issue.

kenny01:08:27

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.

cfleming01:08:48

Yes, definitely both cases need to work.

cfleming01:08:10

Let me just capture all this in an issue and I’ll get you to look it over.

kenny01:08:55

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.

cfleming01:08:35

Yeah, I can’t do that, unfortunately.

cfleming01:08:40

I really hate that thing.

cfleming01:08:58

I should have just duplicated the lein integration, which works great now.

kenny01:08:43

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.

kenny01:08:52

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.

cfleming01:08:59

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.

kenny01:08:18

Ohhh. B's aliases show up in A?

cfleming01:08:37

At least, I think so.

kenny01:08:04

Ah, I had no idea haha. +1 for changing that to be more intuitive 🙂

cfleming01:08:23

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.

cfleming01:08:57

The way that lein works is that there’s one single top-level Profiles tree, which applies globally to all projects.

cfleming01:08:38

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.

kenny01:08:27

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.

cfleming01:08:45

Yes, that is different and configured as you describe for lein.

kenny01:08:46

That's much clearer than the way it is now, IMO.

cfleming01:08:07

Ok, I’ll try to fix that. That would hopefully fix a lot of the confusion.

kenny01:08:02

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.

cfleming01:08:40

Do you mean per-deps.edn, or per-IntelliJ project (i.e. per-all-your-deps.edn)?

kenny01:08:13

per-deps.edn. IntelliJ projects are just a way of viewing many individual deps.edn projects.

cfleming01:08:55

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.

cfleming01:08:43

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.

cfleming01:08:54

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.

kenny01:08:19

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.

cfleming01:08:06

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)

kenny01:08:54

I'm curious if there's other reasons for that. deps.edn has certainly changed my mental model for this stuff.

kenny01:08:46

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.

cfleming01:08:05

Yes, definitely, no plans to change that part.

kenny01:08:08

Maybe some checkboxes in the run configuration box so I can remember what aliases are available in that project? :)

cfleming01:08:20

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.

cfleming01:08:38

Hehe, sure, or autocomplete perhaps.

kenny02:08:34

Thank you so much! This will be a huge fix for us.

cfleming03:08:26

Ok, this sucks. I cannot make that change, nor can I change this in any non-confusing way.

cfleming03:08:05

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.

cfleming03:08:49

Then I’ll be able to do whatever changes I need to, and you’ll have new and exciting bugs to find 🙂

cfleming03:08:54

Sorry for the wait.

kenny03:08:22

Haha it’s ok. Happy to help make Cursive better!

cfleming03:08:47

Cool, I’ll let you know when I have a dev build worth testing.

kenny03:08:23

👍:skin-tone-2:

ghedeon16:08:34

not sure if an issue or I'm using it wrong but sometimes parentheses are being too insistent. Ex: ((foo)) Try to delete one of the parentheses or try to make it (foo). Can't quickly unwrap it.

Joe Lane16:08:44

@asfalit Do you have paredit mode on?

ghedeon16:08:22

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.

ghedeon16:08:36

Ok, it's controlled by Edit -> Toggle Structural Editing Style.

ghedeon16:08:40

And, in case I want to keep it on, then Raise does the unwrapping. Thanks, rubber duck in its glory))

ghedeon16:08:16

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!

kenny16:08:54

I managed to get around the above by launching a nrepl in a terminal and connecting via a Remote REPL. I noticed that a remote REPL does not have all the error highlighting a regular REPL has: