Yeah, this is annoying. I can think of two options, of which I might end up doing both. The obvious one would be to limit the size of the dialog to something sensible, and the other would be to allow entries to be deleted from the history by pressing backspace in the history editor. That would be useful for other things as well, there’s been a case where someone got xml-incompatible unicode in a history item and then lost all their history when IntelliJ tried to save it.

Thanks! I think limiting width will always be needed because people may have long history entries they don't want to delete. Maybe it's as simple as remembering how wide it is when user resizes it and using that width the next time it comes up, but I have no idea what level of control IntelliJ gives you.

I’ll look into that, there must be a way to control that. I developed that thing ages ago, it’s entirely possible I didn’t really know what I was doing when I made it.

Not sure about your usecase there but I have a feeling it's clojure you have to tell that to

No, its cursive because when I autocomplete a namespace in cursive in adds the wrong require at the top of the file

Can you give me an example of Cursive adding the wrong require?

I suppose then it's along the lines of typing (s/def then auto-requiring, and depending on the position of the stars in the night sky it will either require spec or schema.

Similar yeah, it’s a namespace that we have internally that wraps Pathom

I usually get a popup on auto-require when there are multiple namespaces in my project offering the same name

It doesn't seem to work 100% but it does most of the time for me

Yeah I just want to tell cursive what it should do instead of it having to divine my intentions

Similar to indentation config

I think it has to do with the fact that we use the same namespace alias and macro names

and this trips up cursive

but that is just a guess

I see. And you want to use one of them everywhere, or you want to be able to specify in which contexts which gets used?

I would even be happy with just being able to say for this project use this alias when auto-requiring

having further customization might be useful in niche cases but would say it isn’t super important

I get “Manifest type not detected when finding deps..” when using relative paths for override deps in aliases. works fine outside of Cursive

workaround is to use absolute paths but that doesn’t transfer across machines

Hmm, that error used to come up all the time but hasn’t been seen for a while now. I’ll try that and see if I can reproduce.

Can you give me an example of the sort of form which is giving you problems?

sure. here’s the contents of the alias…

{:override-deps {nextdoc/components-portable {:local/root "../components-portable"}
;                                      nextdoc/terse-schema        {:local/root "../terse-schema"}}}

works in terminal/tests/CI. only Cursive fails

if I switch to absolute paths, works everywhere

Ok, and you have other deps projects at those locations, I guess? Does it work if you add :deps/manifest :deps alongside the :local/root entry?

(you shouldn’t have to, but that might be a workaround)

I did try that. no luck unfortunately

I found this which may be related https://clojure.atlassian.net/browse/TDEPS-74

I’ve updated to the latest tools.deps.alpha but no luck there. is this lib bundled in Cursive i.e. you might have an older version bundled?

No, but you might need to go to the deps settings and refresh there to make sure that Cursive has the latest version picked up.

not super urgent but useful for anyone doing mono-repos. seems to be all the rage these days (for good reason)

does it work outside cursive?

Yes, sounds like it does.

I want to say this same thing has been reported re cursive before

Yeah, that error used to be quite frequent but hasn’t been reported for ages now.

But I suspect that it’s just not resolving the path correctly, so deps can’t find the deps.edn to infer the project type from.

yes, running Kaocha tests from terminal using the same alias works fine

correction: using :deps/manifest :deps does change the behaviour. Cursive no longer borks during deps refresh but paths not set correctly i.e. namespace requires fail when loading

the failure in that case is a cljc ns in one of the projects. not sure if it’s specific to cljc files

the cljc files in the upstream project are not “in scope for the module used to start the REPL”

I checked and the alias is included in the run config

I guess we getting to a very specific use-case here

I don’t think so, I think it’s all the same root cause, which is definitely a valid and useful use-case which should work.

ok. what’s the best way for me to provide a repro or debug logs?

I’ll have a go at reproducing with the example you sent, and if I can’t make that work I’ll let you know.

I can reproduce this, it’s definitely a problem with Cursive, due to the fact that Cursive doesn’t invoke deps with the CWD set to the project directory.

I’ll hopefully get that fixed tomorrow.