Fork me on GitHub

Is there some way to limit the width of the dialog that shows up for Tools > REPL > Search REPL History? Sometimes if I have a blob of data copied from somewhere, I'll (def input "string-that-is-hundreds-or-thousands-of-chars-long") for convenience. And now the Search REPL History dialog expands to fill all available space. The dialog is resizable but does not remember its size / position between invocations. I searched preferences and found nothing. This has been a low-key annoyance for a while across multiple IDEA/Cursive versions, but I'm currently on the latest (1.10.2-2021.1)


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.

❤️ 3

Is there a way to tell cursive that a alias should be associated with a specific namespace?


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


Q: is there a problem with Cursive and relative paths in deps.edn aliases?


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’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)

Alex Miller (Clojure team)02:05:47

does it work outside cursive?


Yes, sounds like it does.

Alex Miller (Clojure team)02:05:19

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.

🙏 2

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.

🙏 2