edit: I should have used the cider-jack-in-nrepl-middlewares variable. sorry and thanks 🙏
@bozhidar following previous discussions of nREPL middleware recommended practices, I just learned the following (thanks to a conversation with @tsulej).
The problem with the way I'm recommending to use Clay is that it overrides the
:main-opts, e.g.:https://github.com/scicloj/clay/blob/07b40a/examples/example-project/deps.edn#L7
This means users will lose the usual middleware that is injected by packages such as sayid, java-decompiler, refactor-nrepl.
So, if a tool like Clay wants to inject its own middleware in a graceful way, it needs an Emacs package, like Sayid and other tools have.
Is that right?
It may be related to this: https://github.com/nrepl/nrepl/issues/55
@tsulej explained to me that the following practice would work better: in .dir-locals.el :
((clojure-mode . ((eval . (add-to-list 'cider-jack-in-nrepl-middlewares "scicloj.clay.v1.nrepl/middleware")))))
Yeah, you definite don't need a package per-se, unless you also want to provide some extra Emacs functionality.
As mentioned on GH, I don't think there's also an issue to recommend people to just update their main Emacs setup, if they want to be using some middleware all the time. And I like the concept of Lein plugins (as a Lein user). I never got to using clj much, that's why I still care a lot more about the experience for Lein users. 😄
Thanks! And thank for this reminder to support Lein users, that is important. :)
By the way, the recommendation above
> ((clojure-mode . ((eval . (add-to-list 'cider-jack-in-nrepl-middlewares "scicloj.clay.v1.nrepl/middleware")))))
seems still problematic, since the middleware stays in the list afterwards, and that does not make sense if the user later opens another projects which does not need that middleware.