Fork me on GitHub
#conjure
<
2022-08-02
>
Martynas Maciulevičius06:08:15

I don't know why you don't want to evaluate things but CIDER does that and they don't care. When I open a file then I press ,tn and then it simply runs all the tests in that namespace. If namespace is not loaded then it also loads the namespace. If the related namespaces aren't loaded then it loads them too. I think that by forcing the developer to think about whether they want to load the namespace before running tests you force them to think about incidental complexity that you bring just because you're afraid that they could have code in top level that they for some reason don't want to run. In fact all top-level namespace code is what I want to run. On top of that CIDER has ,ta which runs all tests and loads all namespaces if they're not loaded. They also have a shortcut ,tr which reruns the previous testsuite and ,tl which runs the loaded tests. So in Conjure's case ,ta actually behaves as "run loaded tests" and not "all" tests. So you have to manually visit each namespace and load it to run "all" tests or run all tests from terminal. I think that you don't want to load the namespaces because connection to the REPL is flimsy. It's done in a bad way where it loads babashka REPL when it's not intended. You load it but there is no use because the first thing I do is then start another REPL which means I have a waiting unused Babashka REPL in the background which I won't ever use. And when I start my REPL correctly (because I have to think about which REPL owns which file all the time) then .nrepl-port also exists for babashka REPL it may be useful for some scenarios but then why not support all REPLs out of the box if you support one? In CIDER they have a menu that pops up to choose a REPL. And you can also start multiple REPLs but I didn't use that for one project (maybe my needs were simple).

lispyclouds07:08:10

> I think that you don't want to load the namespaces because connection to the REPL is flimsy. It's done in a bad way where it loads babashka REPL when it's not intended. From my perspective, I wouldn't say its done in a "bad way", but its a default which i guess was chosen as some use cases dictated a need for a quick eval environment and bb fits in well there. This can be disabled https://github.com/Olical/conjure/blob/master/doc/conjure-client-clojure-nrepl.txt#L167

Martynas Maciulevičius07:08:56

I think that this is actually good when you want to do small short-term sessions on small things. But probably I expect too much for long-running session support. And CIDER is tuned for that usecase. So when I try to switch I enter a tool that was built with a somewhat different mindset. I remember when I started to use Spacemacs and I couldn't simply press Ctrl+Z to halt the editor into background. But even if I start bb REPL it starts in the current exact directory. So it's then limited to one package which can import other ones and then it could break the imports (didn't test that one) so there is no project detection if it starts in the current directory.

lispyclouds07:08:54

CIDER and Conjure definitely differ in design decisions and Conjure for me is a bit more "some assembly needed" (one of the reasons could be Clojure isn't the only thing it supports) whereas CIDER is has more stuff built in and makes a lot of choices for you and has a very different runtime. I'd probably ask @U38J3881W for more "why certain things in conjure the way they are?" question, no better source 😄

Martynas Maciulevičius08:08:54

Also not only that -- if you run tests CIDER then also checks if you haven't saved the file. And if you haven't then it prompts you to save it, then loads the file and runs the tests. And you can even make this file saving automatic so that once you press ,tn then it would save, reload and run the tests. Also the shortcuts that evaluate the file and run tests pollute the log so I've bound a key for "clear the log then evaluate buffer" and "clear log and run tests". Because there is no other way to sanely view the individual test results.

lispyclouds08:08:13

As a general preference, I tend to run my REPL outside the editor and connect nvim to it when needed. never really jacked-in even in my CIDER days. my REPLs often outlive the editor and using nvim for a while now, quite into the mode of i wanna shut my editor down asap, which is much much different from the emacs thought process. add to that the thing of running it all inside emacs. and finally my mind likes the fact that i need to assemble some stuff up and that way i have quite the "mine" experience. 😄

lispyclouds08:08:07

A lot of the requirements youre mentioning assume clojure and im not sure something more generic like conjure would have all of that inbuilt. but all of them can be configured.

Martynas Maciulevičius08:08:57

Well I found a plug-in that runs lein repl and it basically behaves the same way as you do: clojure-vim/vim-jack-in This is basically the same as running lein repl. Yes, I think that if there is a tool it has to do one thing well. So I think that this one does well the support for multiple languages in a shallow way.

lispyclouds08:08:12

id say "shallow" is a design decision, its more as "left as an exercise to the user" 😛

lispyclouds08:08:32

all the tooling is there to make it way you want

Martynas Maciulevičius08:08:38

Assembly is a programming language where you can do whatever you want if you have multiple lifetimes for it 😄