This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-05-01
Channels
- # announcements (6)
- # babashka (8)
- # beginners (16)
- # calva (36)
- # clara (3)
- # clerk (6)
- # clj-commons (9)
- # clj-kondo (59)
- # clojure (174)
- # clojure-europe (13)
- # clojure-nl (1)
- # clojure-norway (3)
- # clojure-uk (7)
- # conjure (1)
- # cursive (44)
- # datomic (8)
- # events (1)
- # gratitude (1)
- # hyperfiddle (7)
- # introduce-yourself (1)
- # keechma (1)
- # london-clojurians (1)
- # missionary (2)
- # off-topic (20)
- # ring-swagger (1)
- # squint (37)
out of interest, is it an intellij thing or cursive thing that when i terminate a repl (via stop repl button) , it terminates it with SIGKILL ? is it possible to change this?
It’s an IntelliJ thing that I might be able to customise. What else would you want it to do?
my use case is i'd like to register a jvm shutdown hook on the repl jvm to terminate a background process on exit (an embedded postgres thing) , these don't work with SIGKILL alas
Hmm, I’ll check. I’m not sure what a normal exit would mean in this case, since the REPL server blocks endlessly.
ah yeh i see, i was meaning essentially (System/exit)
or equiv as a jvm shutdown, or a terminate (like ^C) (SIGTERM)
I don’t think I can control the signal, but sending a System/exit might be an option, then just wait 15 seconds or something and then nuke the process if it hasn’t stopped naturally.
yeh something like that would work , that's what we have some supervisor processes do on our services anyway, try to exit then nuke it shortly after
I keep writing edn/read-string
and Cursive keeps automatically adding a require. Which is great! Except it keeps requiring malli.edn
and I want clojure.edn
, which is somewhat irritating. Is there a way I can tell it to stop doing this?
No, but there should be! I’m interested what you would prefer to happen, e.g. some options:
1. Be able to configure that edn
always refers to clojure.edn
.
2. Be able to say that clojure.edn
should always be suggested first in the list.
3. Try to automatically figure out what is more common in your project files (a better option than #2, probably).
I guess I was imagining that if it was automatically requiring stuff it must already be maintaining a list of what edn/...
is used to refer to elsewhere, which is why I was surprised by the behaviour. So I imagine that 3 is what I would expect it to do. That doesn't mean it's the best option though...
If 3 can work that sounds like the best though, as it's less work for the user. If I wanted to spend my life configuring my IDE, I'd be using emacs
(not trolling, there are - I'm sure - other legitimate reasons to use emacs)
I think that #3 is a reasonable default behaviour, and probably perhaps #1 should be possible too. I think #3 is a better option than #2, thinking about it.
When I used Emacs, back in the day, I distinctly remember using 25% of my billable time maintaining the thing.
I did go looking in the settings for some sort of list of what aliases should refer to, so that wouldn't be completely surprising either. It would be nice not to have to though.
Yes, I think just sorting by frequency of use in your actual project files would get most people 95% of the way there, probably without them even noticing it was happening (which is the best sort of productivity improvement).
I'm definitely using way less than 25% of my productive time maintaining IntelliJ/Cursive.

95% correct is probably in the right ball park for automated stuffs - though confirmation bias will always make people remember when it is wrong
Yes, no doubt. But if it just sorts by frequency, on the rare occasions you want something else at least it’s still available, whereas the other hard-coding options wouldn’t allow that.
it's great when you type the whole things out (`edn/read-string`) and then alt-enter gives you a choice of what to require - no magic, all explicit.
it's only guessing when I half type it, and then get the ide to autocomplete it
I was sure there was an issue about this, but I can’t find it - perhaps it was a discussion on the mailing list. But I’ve got it on my list, I’ll try to get to it soon.
in fact - if I just slow down and read the autocomplete popup it does give me the explicit choice
so I think I should change my behaviour, rather than anything else
sorry to have bothered you!
Yes, I have a few improvements for that in mind too. When it happens in a file and there’s a REPL running with the same ns loaded, it would be nice if it were also auto-required in the REPL namespace so you don’t have to reload the ns form to be able to send forms from that file to the REPL.
> if I just slow down and read the autocomplete popup Yes, but who has time for that?
If I have time to talk about it here, then I probably ought to!
I still think it’s a useful change, since I suspect it will always suggest them in the same order. I’m actually not sure off the top of my head how they are ordered, and JetBrains have all sorts of fancy machine learning stuff I could probably hook into for that. But I think just ordering by frequency is probably easy and very useful.
It’s actually possible that if you choose that option manually, then IntelliJ will just magically suggest it to you more since you’ve chosen it more often.
Ok, it’s bedtime for me. But I’ll look at this soon since I think it’s probably an easy win.
don't prioritise is too high!
A big plus one on @U0FR9C8RZ’s experience, I don't know how many times I have been too quick and gotten malli instead of clojure.edn
.
> 3. Try to automatically figure out what is more common in your project files (a better option than #2, probably). It's probably better to just order the list by the latest ns referred by that alias.
How would latest work? Do you mean the most recently added? I guess I could track when each one is added and then use that to sort the list. That might work better for cases where you’re locally working on code using one or the other, but then in another part of the project want to use the other. Is that the sort of thing you have in mind? It does require storing more state than just using the most frequent one.
I meant to remember the last one you chose. I think that would be a good heuristic and probably the most expected by the user. Expanding on that, yes, you could maintain the whole LIFO list of prior choices.
That'd be great. I never use malli.edn
in my project, so I guess Cursive finds it in a dependency or smth.